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

From: Phillip Susi
Date: Mon Feb 13 2006 - 11:50:05 EST


Pekka Enberg wrote:
The UDF code really seems broken. It fails for new inodes and some
chown cases, when the mount options are being used. Phillip's patch
does not look like a complete fix, though, as it will store invalid
uid/gid (-1) for some cases where we probably should be storing the
real uid/gid. For example, doing chown <user> when the same user is
passed as mount option, we'll get -1 on disk, instead of user's uid.

Could you be more specific about what test cases fail? It worked fine for me so far.

Also the storage of -1 id is very much intentional. Prior to this patch, if you mount with uid=yourid then you create a file, it would appear to be owned by you. If you unmounted and remounted the volume however, it would suddenly be owned by root. Clearly that is not acceptable. With this patch applied, the file appears to be owned by you both before and after the remount. The actual value written to disk is -1, which on a read is translated to the value from the mount option, giving the appearance that the file is owned by the user specified in the mount, which is the expected behavior.

Should the desktop user insert this media in another machine where they have a different uid ( that is specified in the mount options ) then they would still have access to their files, as the -1 will be translated to the correct uid on that system.

Should you chown files to a user other than the one given in the mount option, then that actual uid is stored on the disk. Also if you do not specify a uid/gid when you mount, then the actual uid is stored.
I think the semantics you want is: "if uid/gid is invalid on disk,
leave it that way unless we explicitly change it via chown; otherwise
we can always overwrite it." Hmm?

No, the semantics is if the uid/gid on disk is invalid, then use the id specified in the mount options. That was the case before, however when you created new files or chowned files to you ( and you gave your id in the mount options ), an id of 0 was written to disk instead. Now -1 is written, which when read, is mapped back to your id specified in the mount options.


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