From: "Serge E. Hallyn" Subject: Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED Date: Sat, 21 Oct 2017 11:03:02 -0500 Message-ID: <20171021160302.GA2842@mail.hallyn.com> References: <20171021134558.21195-1-nicolas@belouin.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , Theodore Ts'o , Andreas Dilger , Jaegeuk Kim , Chao Yu , David Woodhouse , Dave Kleikamp , Mark Fasheh , Joel Becker , Miklos Szeredi , Phillip Lougher , Richard Weinberger , Artem Bityutskiy , Adrian Hunter , Alexander Viro , Serge Hallyn , Paul Moore , Stephen Smalley , Eric Paris , James Morris , linux-ext4@vger.kernel.o To: Nicolas Belouin Return-path: Content-Disposition: inline In-Reply-To: <20171021134558.21195-1-nicolas@belouin.fr> Sender: owner-linux-security-module@vger.kernel.org List-Id: linux-ext4.vger.kernel.org Quoting Nicolas Belouin (nicolas@belouin.fr): > with CAP_SYS_ADMIN being bloated, the usefulness of using it to > flag a process to be entrusted for e.g reading and writing trusted > xattr is near zero. > CAP_TRUSTED aims to provide userland with a way to mark a process as > entrusted to do specific (not specially admin-centered) actions. It > would for example allow a process to red/write the trusted xattrs. You say "for example". Are you intending to add more uses? If so, what are they? If not, how about renaming it CAP_TRUSTED_XATTR? What all does allowing writes to trusted xattrs give you? There are the overlayfs whiteouts, what else?