On Sun, Dec 15, 2013 at 06:21:52AM -0800, L.A. Walsh wrote: > > > 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. So you want users with no privileges to be able to create and modify security context imformation, such as selinux labels, integrity hashes, etc? Really? > Shouldn't it follow along and be copied much as are the root namespace > entries? There is no "root" attribute namespace that users can manipulate - there is a "trusted" namespace for root users, but that's not what you are talking about. The VFS defined name spaces are: - user - security - trusted (requires CAP_SYS_ADMIN) - system All of the other xattrs fall into these groups. e.g. posix acls: - system.posix_acl_access - system.posix_acl_default What you are doing is conflating how XFS stores xattrs on disk with user visible xattr namespaces. The two are not the same thing. The VFS enforces access to the "trusted" namespace and posix ACLs, security modules enforce access to their own attributes and potentially restrict access to the entire security namespace. Whatever remains is left up to the filesystem to decide access rules. Hence, cp as a user cannot copy trusted xattrs and certain security attributes as a matter of principle, and some security modules only allow security xattr write permission to CAP_SYS_ADMIN (e.g. selinux), and hence cp as a user cannot read and/or write these xattrs to put them on the newly copied file. IOWs, how XFS stores them on disk is irrelevant to access permissions that are enforced by layers above it... > 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. That's never worked. xattrs are only meaningful to the application that created them. Trying to manipulate those xattrs as a user outside the context of the application is almost always going to fail when special permissions are required by the application to manipulate those xattrs. > 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. Access to the security xattr namespace is entirely controlled by the kernel security modules. If you want to use that namespace, you have to follow whatever rules your currently loaded security module enforces. That, in general, means that the only thing you can guarantee is that the security xattr namespace requires CAP_SYS_ADMIN for write access. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
