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
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
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)...