From: Miklos Szeredi <mszeredi@redhat.com>
To: "Eric W . Biederman" <ebiederm@xmission.com>
Cc: linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Serge E . Hallyn" <serge@hallyn.com>,
Tyler Hicks <code@tyhicks.com>
Subject: [PATCH 0/2] capability conversion fixes
Date: Tue, 19 Jan 2021 17:22:02 +0100 [thread overview]
Message-ID: <20210119162204.2081137-1-mszeredi@redhat.com> (raw)
It turns out overlayfs is actually okay wrt. mutliple conversions, because
it uses the right context for lower operations. I.e. before calling
vfs_{set,get}xattr() on underlying fs, it overrides creds with that of the
mounter, so the current user ns will now match that of
overlay_sb->s_user_ns, meaning that the caps will be converted to just the
right format for the next layer
OTOH ecryptfs, which is the only other one affected by commit 7c03e2cda4a5
("vfs: move cap_convert_nscap() call into vfs_setxattr()") needs to be
fixed up, since it doesn't do the cap override thing that overlayfs does.
I don't have an ecryptfs setup, so untested, but it's a fairly trivial
change.
My other observation was that cap_inode_getsecurity() messes up conversion
of caps in more than one case. This is independent of the overlayfs user
ns enablement but affects it as well.
Maybe we can revisit the infrastructure improvements we discussed, but I
think these fixes are more appropriate for the current cycle.
Thanks,
Miklos
Miklos Szeredi (2):
ecryptfs: fix uid translation for setxattr on security.capability
security.capability: fix conversions on getxattr
fs/ecryptfs/inode.c | 10 +++++--
security/commoncap.c | 67 ++++++++++++++++++++++++++++----------------
2 files changed, 50 insertions(+), 27 deletions(-)
--
2.26.2
next reply other threads:[~2021-01-19 18:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-19 16:22 Miklos Szeredi [this message]
2021-01-19 16:22 ` [PATCH 1/2] ecryptfs: fix uid translation for setxattr on security.capability Miklos Szeredi
2021-01-19 21:06 ` Eric W. Biederman
2021-01-20 7:52 ` Miklos Szeredi
2021-01-22 16:04 ` Tyler Hicks
2021-01-22 18:31 ` Tyler Hicks
2021-01-25 13:25 ` Miklos Szeredi
2021-01-25 13:46 ` Miklos Szeredi
2021-01-26 1:52 ` Tyler Hicks
2021-01-19 16:22 ` [PATCH 2/2] security.capability: fix conversions on getxattr Miklos Szeredi
2021-01-20 1:34 ` Eric W. Biederman
2021-01-20 7:58 ` Miklos Szeredi
2021-01-28 16:58 ` Serge E. Hallyn
2021-01-28 20:19 ` Eric W. Biederman
2021-01-28 20:38 ` Miklos Szeredi
2021-01-28 20:49 ` Eric W. Biederman
[not found] ` <20210129154839.GC1130@mail.hallyn.com>
2021-01-29 22:55 ` Eric W. Biederman
2021-01-30 2:06 ` Serge E. Hallyn
2021-01-31 18:14 ` Eric W. Biederman
[not found] ` <CAJfpegt34fO8tUw8R2_ZxxKHBdBO_-quf+-f3N8aZmS=1oRdvQ@mail.gmail.com>
[not found] ` <20210129153807.GA1130@mail.hallyn.com>
2021-01-29 23:11 ` Eric W. Biederman
2021-01-30 2:04 ` Serge E. Hallyn
2021-01-20 19:37 ` kernel test robot
2021-01-20 21:08 ` kernel test robot
2021-01-19 21:10 ` [PATCH 0/2] capability conversion fixes Eric W. Biederman
2021-01-20 7:39 ` Miklos Szeredi
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=20210119162204.2081137-1-mszeredi@redhat.com \
--to=mszeredi@redhat.com \
--cc=code@tyhicks.com \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=serge@hallyn.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).