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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.