public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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

      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