Assuming you aren't using a completely broken hash function (speaking of which, what hash and iteration counts are you using? Are they dynamically selected, and if so how?), what you're doing should work.
More specifically, assuming user 1 knows K1 (their own derived key), salt1 (the salt used to derive K1), and salt2 (user 2's salt), but doesn't know S or K2, they should not be able to derive K2 (or S, which would let them get K2 if they know salt2).
With that said, I can't really recommend this approach; it's not really the way KDFs are specifically meant to be used, and adapting cryptographic functions to new uses is often dangerous. Their security properties are not always what you intuitively think they are.
For example, to a naïve understanding of hash functions, knowing the digest of some blob B (without knowing B), and knowing the suffix X that gets appended to B, should not be enough for you to know the digest of concat(B, X). That is, people usually assume that if you don't know the entire input to a hash function, you can't possibly predict the output... even if you know the output of a different input, and know what change was made to that output (in this case, concatenating a suffix). However, due to length extension attacks, it sometimes can be possible to know what the digest will be after appending a known suffix, even if you don't know the original message.
I don't know that anything similar applies to PBKDF2 (or any other KDFs) but I'm still leery of using them in an unusual way. The purpose of the salt is so that, even if two users unknowingly use the same password, you can't tell it's the same password because the derived keys will be different. If you know from the start that the passwords are the same, I don't believe the function is known to guarantee that no additional information could be derived. Maybe it does, maybe it only does with certain hashes, maybe it doesn't... but I don't know, and I don't know if anybody has studied it.