On 12/15/2013 7:02 PM, Dave Chinner wrote:
It writes it into the "trusted" VFS xattr namespace which means it
knows *nothing* about how XFS stores it's xattrs on disk.
----
I never said it was correct, Dave. At best, I thought it might have
represented some state in the past.
-----
I'm running with the "default" security (Discretionary -
mode bits + access lists + cap bits slowly supplanting need for root.
So, did you turn the distro default selinux config off?
----
Suse ships AppArmor enabled by default, not selinux.
I run my own kernel from kernel.org sources. (Suse doesn't
support booting directly from disk, and /usr is expected
to be mounted when the OS starts coming up (they put mount in
/usr/bin now and a symlink in /bin pointing to /usr/bin.
You missed what I said completely. You didn't create the NT attr,
Samba did it on your behalf. Samba - the aplication that owns the
xattr - has higher privileges than you do, and so it can do things
you can't. Like manage attributes in the security namespace.
---
I didn't miss it -- I was talking about user-proxies. The point of
my running a linux server as a Domain Controller is that I have 1 point
of security on my net -- the server, and whether I log in to a client
or the server, I "should" (conceptually) have access to the same files.
If I ssh from the client to the server, I see a message in messages:
sshd accepted public key for Domain\\linda from [station]...
Samba provides user and group name resolution and security for the
server.
====
As I tried to make clear -- this is a new behavior I'm seeing. I've never
had attrs on my files that I, as the file 'owner' couldn't move around
to permitted locations. As it is an ACL, my feeling is it should be
stored in the same way the posix acls are -- which are copyable.
Then something above the filesystem has changed. We haven't changed
anything to do with who or how xattrs are stored or used in XFS for
a long time.
----
Neither the kernel nor xfs were high on my list of
candidates.
Cheers,
---
and felicitations!...
linda
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
