On 12/13/2013 1:32 PM, L.A. Walsh wrote:
On 12/13/2013 2:53 AM, Christoph Hellwig wrote:
> On Fri, Dec 13, 2013 at 12:39:40AM -0800, L.A. Walsh wrote:
>
>> Does it have to be under a "namespace" that gets *stripped*
>> as soon as the file is copied or "mv'd to another
>> samba share (i.e. the partition it was moved to is shared with the
>> same permissions as the first one.
>
> Attributes never get "stripped", they simple don't get copied unless
> explicit action is taken to do so. Setting trusted attributes up on a
> new file will of course rely privilegues, exactly for the reasons
> Jeremy pointed out.
-----
For what purpose? As it stands the security namespace doesn't seem
very useful -- i.e. the 'root' attrs get copied and/or moved on a file
copy/rename which carries the access along with the file contents.
But I fail to see the usefulness in having a security namespace that
is dropped by default on copies or inter-partition moves.
Shouldn't it follow along and be copied much as are the root namespace
entries?
It gets really confusing if a "proxy service" (ex. file server)
for the user, stores attributes in that namespace thinking they will
somehow be useful when the user accesses the file w/o the proxy service --
i.e. as a normal file.
Was there a specific use-case for being able to tag files with security
attrs that can't be copied, moved or renamed except by root that wouldn't
better be served by signed or 'sealed' (encrypted) content? For most
cases, it would seem that signing to detect tampering would be enough,
though I can think of cases where sealing to prevent knowledge of
who has what access would also be useful.
Something to think about before others try to use the security field to
store attrs they want kept with the content and not the inode.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
