From: Miklos Szeredi <miklos@szeredi.hu>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Andreas Gruenbacher <agruenba@redhat.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
virtio-fs-list <virtio-fs@redhat.com>,
Daniel J Walsh <dwalsh@redhat.com>,
Christian Brauner <christian.brauner@ubuntu.com>,
Casey Schaufler <casey.schaufler@intel.com>,
LSM <linux-security-module@vger.kernel.org>,
SElinux list <selinux@vger.kernel.org>,
"Theodore Ts'o" <tytso@mit.edu>,
Giuseppe Scrivano <gscrivan@redhat.com>,
"Fields, Bruce" <bfields@redhat.com>,
Stephen Smalley <stephen.smalley.work@gmail.com>,
Dave Chinner <david@fromorbit.com>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH v3 0/1] Relax restrictions on user.* xattr
Date: Wed, 8 Sep 2021 09:37:17 +0200 [thread overview]
Message-ID: <CAJfpegumUMsQ1Zk4MjnSXhrcnX_RJfM5LJ2oL6W3Um_wFNPRFQ@mail.gmail.com> (raw)
In-Reply-To: <YTfcT1JUactPhwSA@redhat.com>
On Tue, 7 Sept 2021 at 23:40, Vivek Goyal <vgoyal@redhat.com> wrote:
>
> On Mon, Sep 06, 2021 at 04:56:44PM +0200, Miklos Szeredi wrote:
> > On Mon, 6 Sept 2021 at 16:39, Dr. David Alan Gilbert
> > <dgilbert@redhat.com> wrote:
> >
> > > IMHO the real problem here is that the user/trusted/system/security
> > > 'namespaces' are arbitrary hacks rather than a proper namespacing
> > > mechanism that allows you to create new (nested) namespaces and associate
> > > permissions with each one.
> >
> > Indeed.
> >
> > This is what Eric Biederman suggested at some point for supporting
> > trusted xattrs within a user namespace:
> >
> > | For trusted xattrs I think it makes sense in principle. The namespace
> > | would probably become something like "trusted<ns-root-uid>.".
> >
> > Theory sounds simple enough. Anyone interested in looking at the details?
>
> So this namespaced trusted.* xattr domain will basically avoid the need
> to have CAP_SYS_ADMIN in init_user_ns, IIUC. I guess this is better
> than giving CAP_SYS_ADMIN in init_user_ns.
That's the objective, yes. I think the trick is getting filesystems
to store yet another xattr type.
Thanks,
Miklos
next prev parent reply other threads:[~2021-09-08 7:37 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-02 15:22 [PATCH v3 0/1] Relax restrictions on user.* xattr Vivek Goyal
2021-09-02 15:22 ` [PATCH v3 1/1] xattr: Allow user.* xattr on symlink and special files Vivek Goyal
2021-09-02 15:38 ` [PATCH 2/1] man-pages: xattr.7: Update text for user extended xattr behavior change Vivek Goyal
2021-09-02 15:43 ` [PATCH v3 0/1] Relax restrictions on user.* xattr Casey Schaufler
2021-09-02 17:05 ` Vivek Goyal
2021-09-02 17:42 ` Vivek Goyal
2021-09-02 18:55 ` Casey Schaufler
2021-09-02 20:06 ` Vivek Goyal
2021-09-02 22:34 ` Casey Schaufler
2021-09-03 15:26 ` Vivek Goyal
2021-09-03 18:49 ` Casey Schaufler
2021-09-06 7:45 ` [Virtio-fs] " Sergio Lopez
2021-09-06 14:55 ` Dr. David Alan Gilbert
2021-09-13 19:05 ` Casey Schaufler
2021-09-14 12:51 ` Vivek Goyal
2021-09-14 13:56 ` Casey Schaufler
2021-09-14 13:59 ` Bruce Fields
2021-09-14 14:32 ` Vivek Goyal
2021-09-14 15:01 ` Bruce Fields
2021-09-15 16:33 ` Dr. Greg
2021-09-02 15:47 ` [PATCH 3/1] xfstests: generic/062: Do not run on newer kernels Vivek Goyal
2021-09-03 4:55 ` Dave Chinner
2021-09-03 6:31 ` Andreas Gruenbacher
2021-09-03 6:56 ` Andreas Gruenbacher
2021-09-03 14:42 ` Bruce Fields
2021-09-03 15:43 ` Vivek Goyal
2021-09-03 15:50 ` Bruce Fields
2021-09-03 16:01 ` Casey Schaufler
2021-09-03 16:03 ` Vivek Goyal
2021-09-03 6:31 ` Zorro Lang
2021-09-02 15:50 ` [PATCH 4/1] xfstest: Add a new test to test xattr operations Vivek Goyal
2021-09-02 17:52 ` [PATCH v3 0/1] Relax restrictions on user.* xattr Andreas Gruenbacher
2021-09-02 18:48 ` Vivek Goyal
2021-09-02 19:19 ` Casey Schaufler
2021-09-06 14:39 ` Dr. David Alan Gilbert
2021-09-06 14:56 ` Miklos Szeredi
2021-09-07 21:40 ` Vivek Goyal
2021-09-08 7:37 ` Miklos Szeredi [this message]
2021-09-08 14:20 ` Eric W. Biederman
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=CAJfpegumUMsQ1Zk4MjnSXhrcnX_RJfM5LJ2oL6W3Um_wFNPRFQ@mail.gmail.com \
--to=miklos@szeredi.hu \
--cc=agruenba@redhat.com \
--cc=bfields@redhat.com \
--cc=casey.schaufler@intel.com \
--cc=christian.brauner@ubuntu.com \
--cc=david@fromorbit.com \
--cc=dgilbert@redhat.com \
--cc=dwalsh@redhat.com \
--cc=ebiederm@xmission.com \
--cc=gscrivan@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=selinux@vger.kernel.org \
--cc=stephen.smalley.work@gmail.com \
--cc=tytso@mit.edu \
--cc=vgoyal@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=virtio-fs@redhat.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;
as well as URLs for NNTP newsgroup(s).