New: Move restrict_chown to mount-time option
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · Christoph Hellwig
Quoted 6 lines · On Wed, Sep 05, 2007 at 11:31:54AM -0700, [email protected] wrote:
We've run into a situation where it would be extremely advantageous to be able to
restrict_chownon certain volumes on a server but not on others. I'm not real familiar with kernel internals, programming, etc., but I'd like to suggest thatrestrict_chownbe made a mount option for an XFS filesystem instead of a system-wide, sysctl/proc option. This would allow finer control over which filesystems restrict giving away files and which don't.It's quite easily doable. I don't have time for that right now, but if anyone wants to do it's just adding the option to the mount option parser and adding a flag to the mount structure.
Wouldn't making this a generic mount-option make sense? Or is it far too low-level of a concept?
Josef 'Jeff' Sipek.
Signature · 1 line
I already backed up the [server] once, I can do it again.
Quoted 6 lines · Josef Sipek
Quoted 3 lines
It's quite easily doable. I don't have time for that right now, but if anyone wants to do it's just adding the option to the mount option parser and adding a flag to the mount structure.
Wouldn't making this a generic mount-option make sense? Or is it far too low-level of a concept?
Basically it's a simple boolean flag that's checked in the inode allocator when we decide about the permission of the newly created inode. Because of that the implementation will be inherently filesystem-specific. We could still add a binary mount flag for it in common code, but my stance is to only add these when we actually need to check the flag in general code.
Quoted 5 lines · Christoph Hellwig
Quoted 4 lines · Josef Sipek
Quoted 3 lines
It's quite easily doable. I don't have time for that right now, but if anyone wants to do it's just adding the option to the mount option parser and adding a flag to the mount structure.
Quoted 7 lines
Quoted 2 lines
Wouldn't making this a generic mount-option make sense? Or is it far too low-level of a concept?
Basically it's a simple boolean flag that's checked in the inode allocator when we decide about the permission of the newly created inode. Because of that the implementation will be inherently filesystem-specific.
Couldn't that be done just before the call to ->create as a mask on the mode?
Quoted 3 lines
We could still add a binary mount flag for it in common code, but my stance is to only add these when we actually need to check the flag in general code.
Or if the feature is so useful that all fs should support it. Is it useful? If not, then I agree, not cluttering the VFS is a Good Thing.
Josef 'Jeff' Sipek.
Signature · 4 lines
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan
Quoted 9 lines · Josef Sipek
Quoted 8 lines · Christoph Hellwig
Quoted 6 lines · Josef Sipek
Quoted 3 lines
It's quite easily doable. I don't have time for that right now, but if anyone wants to do it's just adding the option to the mount option parser and adding a flag to the mount structure.
Wouldn't making this a generic mount-option make sense? Or is it far too low-level of a concept?
Quoted 7 lines
Quoted 4 lines
Basically it's a simple boolean flag that's checked in the inode allocator when we decide about the permission of the newly created inode. Because of that the implementation will be inherently filesystem-specific.
Couldn't that be done just before the call to ->create as a mask on the mode?
Sorry, my post above was talking about the bsd group semantics for which we had a similar discussion before. For restricted_chown the method handling it is ->setattr and given how it's defined to be filesystem specific I can't see how to do it generically.
Quoted 6 lines
Quoted 3 lines
We could still add a binary mount flag for it in common code, but my stance is to only add these when we actually need to check the flag in general code.
Or if the feature is so useful that all fs should support it. Is it useful? If not, then I agree, not cluttering the VFS is a Good Thing.
It's not really a feature, more a workaround for legacy behaviour in other Unix variants. It basically disallows chown in some cases where it's normally allowed.