Re: [RFC][PATCH] UDF filesystem uid fix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Pekka J Enberg wrote:
I don't haven an UDF partition to test on so I am only reading the code. With your patch, every time an in-memory inode has the same uid/gid as the one you passed as mount option, the id on disk will become -1, no? So for example, doing chown 100 for a file writes -1 to disk if you passed 100 as uid mount option. Am I missing something here?

That is exactly correct.
Yes, I agree that the current code is broken. I was talking about what the semantics should be and that your patch doesn't quite get us there. Do you disagree with that? The UDF specification I am looking at [1] says that -1 is used by operating systems that do not support uid/gid to denote an invalid id (although ECMA-167 doesn't seem to have such rule), which is why I think it's an bad idea for Linux to ever write it on disk. Instead, we should always write the proper id on disk unless it was invalid in the first place and we did not explicity change it (via chown, for example).
Sometimes you DON'T want a valid UID written to the disk. In the case of a typical desktop user, there is only one uid that is ever going to access the disk, but that uid may be different on each computer, even though it's the same person. Thus they want to be able to take the disc from computer to computer, and have access to their files. Since the existing uid/gid override mount options only apply if the on disk id is -1, it seemed a simple and appropriate thing to store -1 in the case where the id matches the mount option. The only use case that this patch changes is where the id matches the mount option. In that case, the user expected behavior is for the files on the disc to appear to be owned by the specified uid, with the added benefit that this will hold true if you remount with another uid specified, possibly even on another machine. This seems to meet user expectations much better than the previous behavior of changing ownership to root when unmounted. If you want real IDs to be stored, then do nothing. Simply continue to use the system just like before, where you did not specify a uid as a mount option.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux