From: Linda Walsh <xfs@tlinx.org>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: BUG: ACL's are a security attribute. They belong in the Security attrib space, not the Root-attrib space.
Date: Tue, 23 Jul 2013 21:37:47 -0700 [thread overview]
Message-ID: <51EF5A1B.6020005@tlinx.org> (raw)
In-Reply-To: <20130724040525.GQ19986@dastard>
Dave Chinner wrote:
> On Tue, Jul 23, 2013 at 02:29:42PM -0700, Linda Walsh wrote:
> > 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
-----
That makes the man page even more dated...
Why don't we copy your explanation into the manpage! It's certainly
more clear! ;-)
>
> > 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?
>
> #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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2013-07-24 4:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-23 21:29 BUG: ACL's are a security attribute. They belong in the Security attrib space, not the Root-attrib space Linda Walsh
2013-07-24 4:05 ` Dave Chinner
2013-07-24 4:37 ` Linda Walsh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51EF5A1B.6020005@tlinx.org \
--to=xfs@tlinx.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox