From: "L.A. Walsh" <samba@tlinx.org>
To: xfs-oss <xfs@oss.sgi.com>
Subject: Re: BTW - to xfs folk, 'security attr' doesn't seem very useful w/current copy policies
Date: Sun, 15 Dec 2013 06:21:52 -0800 [thread overview]
Message-ID: <52ADBB00.8050707@tlinx.org> (raw)
In-Reply-To: <52AB7CDC.5040801@tlinx.org>
On 12/13/2013 1:32 PM, L.A. Walsh wrote:
> On 12/13/2013 2:53 AM, Christoph Hellwig wrote:
> > On Fri, Dec 13, 2013 at 12:39:40AM -0800, L.A. Walsh wrote:
> >
> >> Does it have to be under a "namespace" that gets *stripped*
> >> as soon as the file is copied or "mv'd to another
> >> samba share (i.e. the partition it was moved to is shared with the
> >> same permissions as the first one.
> >
> > Attributes never get "stripped", they simple don't get copied unless
> > explicit action is taken to do so. Setting trusted attributes up on a
> > new file will of course rely privilegues, exactly for the reasons
> > Jeremy pointed out.
-----
For what purpose? As it stands the security namespace doesn't seem
very useful -- i.e. the 'root' attrs get copied and/or moved on a file
copy/rename which carries the access along with the file contents.
But I fail to see the usefulness in having a security namespace that
is dropped by default on copies or inter-partition moves.
Shouldn't it follow along and be copied much as are the root namespace
entries?
It gets really confusing if a "proxy service" (ex. file server)
for the user, stores attributes in that namespace thinking they will
somehow be useful when the user accesses the file w/o the proxy service --
i.e. as a normal file.
Was there a specific use-case for being able to tag files with security
attrs that can't be copied, moved or renamed except by root that wouldn't
better be served by signed or 'sealed' (encrypted) content? For most
cases, it would seem that signing to detect tampering would be enough,
though I can think of cases where sealing to prevent knowledge of
who has what access would also be useful.
Something to think about before others try to use the security field to
store attrs they want kept with the content and not the inode.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-12-15 14:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <52A96211.3050602@tlinx.org>
[not found] ` <20131212181315.GB20500@samba2>
[not found] ` <52AAC7CC.8000802@tlinx.org>
[not found] ` <20131213105314.GA2117@infradead.org>
2013-12-13 21:32 ` Security issue - storing NTACL's in non-NT-security-namespace L.A. Walsh
2013-12-13 22:08 ` Jeremy Allison
2013-12-13 22:14 ` L.A. Walsh
2013-12-13 23:20 ` Dave Chinner
2013-12-15 14:21 ` L.A. Walsh [this message]
2013-12-15 23:54 ` BTW - to xfs folk, 'security attr' doesn't seem very useful w/current copy policies Dave Chinner
2013-12-16 2:20 ` usefulness of 'security attr' being non-copiable on discretionary access linux LA Walsh
2013-12-16 3:02 ` Dave Chinner
2013-12-16 7:41 ` LA Walsh
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=52ADBB00.8050707@tlinx.org \
--to=samba@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