where/how is 'xattr' type=security enforced? (security attr stripped?)

[Linda Walsh <xfs@tlinx.org>]

I got a weird message that I've never seen before -- nothing
life shattering, just a curiosity that I thought shouldn't happen.


I stored a file in my /home partition FROM a Win7 client
via samba 3.6.16.

With that file were also stored xattrs:

DOSATTRIB, SAMBA_PAI and NTACL.  Since linux is the 'server',
These are all likely set via samba.

To work on the file more, I wanted to move it
to /tmp.

I use mv:
> mv  /home/law/tmp/oVars.pm /tmp
mv: setting attribute ‘security.NTACL’ for ‘security.NTACL’: Operation not permitted

"I" was the owner of the file (same UID is resolved for NT-user & local user) and
local user is in group that file was stored under.

I am trying to figure out where this message came from, as 'mv' doesn't
do any access enforcement based on the 'xattr' name field.

The impact of this is I can't move the file without losing security
which is automatically stripped.

Trying to *copy* the file within the same directory also results
in the security xattr being stripped -- but ***silently***.

So what was responsible for prohibiting the moving the the xfs 'xattr'?

My thoughts on this are that if I, as a user can write such a file
(to my home dir in this case) and the attributes are created (indirectly)
by "me" when I create the file, I should also be able to move the file
**intact** with the NTACL maintained.

In both cases, the file system types are the same (xfs).  The creator
and the mover are the same UID.  Both file systems can be accessed
via my Win7 Client.

So anyone know why this fails or why it is silently stripped on a
"cp"?

Thanks...(maybe a kernel bug?)


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs