Re: Inconsistencies with trusted.SGI_ACL_{FILE,DEFAULT}

From: Dave Chinner <david@fromorbit.com>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Brian Foster <bfoster@redhat.com>, xfs@oss.sgi.com
Subject: Re: Inconsistencies with trusted.SGI_ACL_{FILE,DEFAULT}
Date: Wed, 28 Oct 2015 09:38:14 +1100	[thread overview]
Message-ID: <20151027223814.GN19199@dastard> (raw)
In-Reply-To: <CAHc6FU4dXfXyTBW2GgckeqaLGuUwney32orV6=M8VA+ix5h1Uw@mail.gmail.com>

On Tue, Oct 27, 2015 at 10:39:51PM +0100, Andreas Gruenbacher wrote:
> On Tue, Oct 27, 2015 at 9:18 PM, Dave Chinner <david@fromorbit.com> wrote:
> > Further, user namespaces are irrelevant here - you can't run
> > xfsdump/restore outside the init_ns.  xfsdump requires access to the
> > handle interface, which is unsafe to use inside a user ns because it
> > allows complete access to any inode in the filesystem without
> > limitations. xfs_restore requires unfettered access to directly
> > manipulate the uid/gid/security attrs of inodes, which once again is
> > something that isn't allowed inside user namespaces.
> >
> > Setting Posix acls by directly poking the on-disk attr format rather
> > than going through the proper kernel ACL namespace is not a *general
> > purpose user interface*.  Thi exists for backup/restore utilities to
> > do things like restore ACLs and security labels simply by treating
> > them as opaque xattrs.  If a user sets ACLs using this low level
> > "opaque xattr" method, then they get to keep all the broken bits to
> > themselves.
> 
> Any process capable of CAP_SYS_ADMIN can getxattr and setxattr those

CAP_SYS_ADMIN = enough rope to hang yourself.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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