On Thu, May 10, 2012 at 05:00:24PM +0200, Jan Kara wrote: > I've looked at this in more detail now. Although it would be nice to > avoid duplicating the the functionality as others suggested, I agree it's > not that simple and it seems to me we'd end up doing similar amount of work > in the filesystems anyway (mount option parsing, writing to disk, printing > mount options, ...). So I'm ok with the implementation as is and I'd be > willing to take it for ext3 / ext2. But we really want to keep all ext? > filesystems consistent so this also depends on Ted's approval of the change > for ext4. Ted? Grumble. I agree, reluctantly. As much as I would like to make this be generic, it looks like the amount of glue code to allow the VFS to parse text-based mount options, and change the uid/gid fields after it is read from disk and before writing to disk is probably more than the code that we could be able to factor out. > What I'm missing in the changelog description is what i_diskuid/i_diskgid > is good for. Although I can imagine some use case, I'm not sure I can see > any sufficiently convicing one... I'd much rather force diskuid and diskgid to 0 if the uid or gid is specified, and if uid or gid option is in force, we force nosuid to be on, to avoid the very obvious security problems if a sysadmin isn't super careful. The use case is going to be for things like USB sticks where it's not likely that the sysadmin will be taking appropriate care, so keeping things simple is probably a good thing. > Also please split the patch in three separate patches for ext2, ext3, and > ext4. Thanks. Yes, please. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
