All of lore.kernel.org
 help / color / mirror / Atom feed
From: "L.A. Walsh" <samba@tlinx.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Samba Technical <samba-technical@lists.samba.org>,
	Jeremy Allison <jra@samba.org>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: Security issue - storing NTACL's in non-NT-security-namespace
Date: Fri, 13 Dec 2013 13:32:12 -0800	[thread overview]
Message-ID: <52AB7CDC.5040801@tlinx.org> (raw)
In-Reply-To: <20131213105314.GA2117@infradead.org>

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.
>   
----

Stripping is the default action when copying or moving unless you
take some *non-default* (and unspecified) action, AND providing you
even know they are there..

The same is NOT true for the *real* xfs-ACLS -- which are
copied w/o issue.


Example,

testfile.txt (saved via win7 as a normal user in my Doc dir:
(letter on left is my abbrieviation

  Ishtar:law/Documents> attr -l testfile.txt
U  Attribute "DOSATTRIB" has a 56 byte value for testfile.txt
R  Attribute "SGI_ACL_FILE" has a 64 byte value for testfile.txt
U  Attribute "SAMBA_PAI" has a 31 byte value for testfile.txt
S  Attribute "NTACL" has a 328 byte value for testfile.txt      

Then copy using "explicit action" (-a) to save extended attributes:

 Ishtar:law/Documents> cp -a testfile.txt testcopy.txt
 Ishtar:law/Documents> attr -l testcopy.txt
   Attribute "DOSATTRIB" has a 56 byte value for testcopy.txt
   Attribute "SGI_ACL_FILE" has a 64 byte value for testcopy.txt
   Attribute "SAMBA_PAI" has a 31 byte value for testcopy.txt

Now NOTE: if I don't use "explicit action" (-a) in my copy:

 Ishtar:law/Documents> /usr/bin/cp testfile.txt testcopy.txt
 Ishtar:law/Documents> attr -l testcopy.txt                
   Attribute "SGI_ACL_FILE" has a 76 byte value for testcopy.txt

ONLY the root-namespace ACL is save  -- the user and security
attributes are striped.

If I try "mv"ing the -- on the same volume, I am "fine" (attributes
don't get dropped).

But if I cross a file boundary (to another XFS partition):

 Ishtar:law/Documents> mv testfile.txt /Share/CPAN/
   mv: setting attribute ‘security.NTACL’ for ‘security.NTACL’:
       Operation not permitted
 Ishtar:law/Documents> attr -l /Share/CPAN/testfile.txt
   Attribute "DOSATTRIB" has a 56 byte value for /Share/CPAN/testfile.txt
   Attribute "SGI_ACL_FILE" has a 64 byte value for
    /Share/CPAN/testfile.txt
   Attribute "SAMBA_PAI" has a 31 byte value for /Share/CPAN/testfile.txt


Only the Security attribute is stripped.  the root namespace is copyable
by a user


Note.  I saw this message for the 1st time, last week (the permission
message on the move).  Do you have any idea what might have caused
such a change?

Did Samba changed namespaces, or is some library refusing to copy this
or maybe a kernel change?



_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

       reply	other threads:[~2013-12-13 21:33 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       ` L.A. Walsh [this message]
2013-12-13 22:08         ` Security issue - storing NTACL's in non-NT-security-namespace Jeremy Allison
2013-12-13 22:14           ` L.A. Walsh
2013-12-13 23:20           ` Dave Chinner
2013-12-15 14:21         ` BTW - to xfs folk, 'security attr' doesn't seem very useful w/current copy policies L.A. Walsh
2013-12-15 23:54           ` 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=52AB7CDC.5040801@tlinx.org \
    --to=samba@tlinx.org \
    --cc=hch@infradead.org \
    --cc=jra@samba.org \
    --cc=samba-technical@lists.samba.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.