Skip to contentSkip to conversation

BUG: ACL's are a security attribute. They belong in the Security attrib space, not the Root-attrib space.

DISCUSSION Linda Walsh 2 participants 3 messages Jul 23, 2013 – Jul 24, 2013

lore
Share & tools
lore
#0 lore raw

Currently there are 3 disjoint attribute spaces on files -- user, root and security.

(there is a misprint in the manual that says there is 2, but later, it gives talks about using no switch giving the User attrib space, -R for Root attrib space, and -S for the Security attrib space).

Of these, the ACL's are being placed in the root, which might describe file types, or other OS related info, but not security attributes like ACL's. They should be in the Security attrib space (otherwise what is the point of a Security attribute space).

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#1 lore raw
Quoted 6 lines · Linda Walsh

Currently there are 3 disjoint attribute spaces on files -- user, root and security.

(there is a misprint in the manual that says there is 2, but later, it gives talks about using no switch giving the User attrib space, -R for Root attrib space, and -S for the Security attrib space).

You're confusing on-disk formats used to store attributes with namepaces used to report and access them. Linux has security, system, trusted and user namespaces, while on disk XFS has "root", "secure", and "user" spaces.

i.e.

Linux attr XFS on disk
system root
security secure
trusted root
user user

Quoted 4 lines

Of these, the ACL's are being placed in the root, which might describe file types, or other OS related info, but not security attributes like ACL's. They should be in the Security attrib space (otherwise what is the point of a Security attribute space).

Posix ACLS are defined by the *kernel* to be in the "system" namespace:

#define POSIX_ACL_XATTR_ACCESS "system.posix_acl_access" #define POSIX_ACL_XATTR_DEFAULT "system.posix_acl_default"

IOWs, the Linux *kernel* doesn't consider ACLs to be part of the security namespace, and so neither does XFS.

Cheers,

Dave.

Signature · 7 lines
Dave Chinner
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
#2 lore raw
Quoted 12 lines · Dave Chinner
Quoted 5 lines · Linda Walsh

Currently there are 3 disjoint attribute spaces on files -- user, root and security.

(there is a misprint in the manual that says there is 2, but later, it gives talks about using no switch giving the User attrib space, -R for Root attrib space, and -S for the Security attrib space).

You're confusing on-disk formats used to store attributes with namepaces used to report and access them. Linux has security, system, trusted and user namespaces, while on disk XFS has "root", "secure", and "user" spaces.

Quoted 7 lines

i.e.

Linux attr XFS on disk
system root
security secure
trusted root
user user

-----
That makes the man page even more dated...

Why don't we copy your explanation into the manpage! It's certainly more clear! ;-)

Quoted 8 lines
Quoted 5 lines

Of these, the ACL's are being placed in the root, which might describe file types, or other OS related info, but not security attributes like ACL's. They should be in the Security attrib space (otherwise what is the point of a Security attribute space).

Posix ACLS are defined by the *kernel* to be in the "system" namespace:

----
Likely because the system namespace predates the secur[e/ity] namespace,
which seems like it might have been the timeframe that part in the "attr" manpage, saying there were only 2 namespaces, was written?

Quoted 6 lines

#define POSIX_ACL_XATTR_ACCESS "system.posix_acl_access" #define POSIX_ACL_XATTR_DEFAULT "system.posix_acl_default"

IOWs, the Linux *kernel* doesn't consider ACLs to be part of the security namespace, and so neither does XFS.

-----
Well, of the kernel I can understand why ... and then it
makes sense that XFS would have followed the kernel through its evolution...;-)

So that still leaves the Q's about the -l (--list) function no longer being maitained, and the suggested alternates having no similar functionality nor any for the 'root' or 'secur' namespaces.

Maybe not important, but sometimes linux security looks a bit like it is partaking of
security through obscurity...or it could just be generally obscure engineer writing...;-)

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs