On 12/9/2013 9:52 PM, Dave Chinner wrote:
You need root permissions to set security namespace attributes.
---- I knew that about the root namespace, but the security namespace isn't as well documented. I'd *hoped* for something that made 'sense' -- like the owner being able to set/change, at least some of them, like mode bits. I know this isn't a problem, actually "in XFS", but more in how it is used. Thinking out loud...if you'll bare w/me: Since it's an NTACL, on a file created and owned me, in a directory that I 'own' the ACL for (as I'm the owner of the file and the dir it is in), it seems Samba is trying to follow NT rules in placing the ACL w/the file. But then the linux utils come along and change the rules and strip off the NT-ACL, when the file is copied or when it is moved to a different partition (also XFS). What about the posix ACL's? Aren't they in the security section as well? Do they get stripped off whenever a copy is made or the file is moved to another XFS file system? The NTACL was set on the file because it inherited permissions under 'NT' rules. Shouldn't I be able to copy or move the file (presuming I am the owner and directory owner, etc..). What about posix ACL's? It seems to me, that the security section of an ACL should be (assuming you have the normal, discretionary access system on linux), should be movable and settable by the file owner. Under a different security setup (say with mandatory access rules -- like under SMACK or Flask) it would be a different matter, but it seems a bit odd to be stripping ACL's from a file just because it is copied/moved...
[ On a side note, there's some sooper seekrit voodoo ....
yeah, vaguely remember that... FWIW -- I've never seen a message like I'm getting now... so don't know if it is a change in Samba/coreutils or the kernel (all of which have changed recently in installing a new suse release for most things)... _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
