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

[Andreas Gruenbacher <agruenba@xxxxxxxxxx>]

On Tue, Oct 27, 2015 at 9:18 PM, Dave Chinner <david@xxxxxxxxxxxxx> 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
xattrs, it doesn't matter whether it's xfsdump/restore or something
else. Some will mess with those attributes simply because listxattr
lists them and so they will get and set them like all other
attributes. Setting those attributes must not leave the system in an
inconsistent state, independent of what xfsdump/restore happens to do
with them.

Thanks,
Andreas