Security issue - storing NTACL's in non-NT-security-namespace

[L.A. Walsh]

I upgraded a few things on my system and have noticed a problem.

I saved a file from Win7 -> samba share (using XFS)

With the file was saved "security.NTACL" (and 2 other xattrs).

I wanted to work on the file on a different partition
also using XFS.  The "mv" operation displayed an error that
the "security.NTACL" xattr was not able to be set on the
destination (permission denied).

I also found doing a 'cp' from "theFile" => "thefile2"
silently stripped the 'security.NTACL'.

Is it intentional that NTACLs should be so easily stripped
off by normal copy/move operations?

I think, at issue, is that samba shouldn't use a 'root-priv-only'
"security" xattr, to store an ***Application*** attribute.

The NTACL, on a foreign OS (like linux), is not a system security
attribute -- Samba is an application running on linux, but it is
not a linux-system nor, normally, a linux-security application.

Using the security xattr space for a non-OS-native security field
disallows the field staying with the file if it is copied or moved.
I see this as being a problem.

NOTE: It wouldn't be a problem if the "security" field was
      modifiable by the "owner" of the file.  There is a "root"
      xattr namespace that is clearly designed for accessibility,
      only by root. 

      But security attributes on a file (those that are
      "Discretionary" -- like NTACL's), are meant to be
      user-discretionary -- like any posix-acl's that are used,
      as well as the file-mode bits and it's group field (user
      being able to chgrp between groups they are in).

"Ideally" -- I see no reason why there should be 2 "root-only" namespaces
"root" + "security".  Especially, if use of either of those fields
is stripped off by doing a copy or move to another partition, but
unless the security field becomes user-copyable (if it needs to be
tamper proof, maybe it needs signing -- not a member of a non-copyable
field?).

This came up because -- as a user, I stored a file, and, as the same
authorized user (running domain security) -- I couldn't move or copy my
own file and have it maintain it's security integrity.