From: Sander Smeenk <ssmeenk@freshdot.net>
To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: CAP(abilities) and NFS mounted storage
Date: Tue, 13 Oct 2015 19:52:33 +0200 [thread overview]
Message-ID: <20151013175233.GF10632@dot.dmz.freshdot.net> (raw)
In-Reply-To: <CAN-5tyFNor0HmY5xMM7EVfGtec8U2iUVk8942xzC6sAP4Yn4sA@mail.gmail.com>
Quoting Olga Kornievskaia (aglo@umich.edu):
> >> > I've experimented with different capabilties, but CAP_DAC_OVERRIDE is
> >> > not enough. I'd very much like to hear if it is possible for this to
> >> > work on NFS like it does on local storage.
> >> This will not work on NFS. The server, which enforces permissions, has
> >> no way to know what capabilities your process has on the client.
> > Thanks. I feared this answer. But i understand that the NFS-server cant
> > know if the process on the NFS-client has CAP_DAC_READ_SEARCH
> > capabilities set.
> > Would setfsuid() help anything in this case? Or is it just a big no-go?
>
> Are you looking for something like labeled NFS that supports
> capabilities? I think Redhat7 has SElinux labeled NFS support.
SELinux might be a bit too much for our situation. ;)
I'm looking for an answer to who exactly controls filesystem access
permission checks when dealing with files on an NFS mount, and perhaps
an answer to why these permission checks seem to differ for files on NFS
mounts and files on locally attached storage w/ strict capabilities set.
Regards,
-Sndr.
--
| Have you ever imagined a world with no hypothetical situations?
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2
prev parent reply other threads:[~2015-10-13 17:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 12:21 CAP(abilities) and NFS mounted storage Sander Smeenk
2015-10-13 13:33 ` Trond Myklebust
2015-10-13 14:34 ` Sander Smeenk
2015-10-13 15:02 ` Olga Kornievskaia
2015-10-13 15:13 ` Trond Myklebust
2015-10-13 17:59 ` Sander Smeenk
2015-10-13 17:52 ` Sander Smeenk [this message]
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=20151013175233.GF10632@dot.dmz.freshdot.net \
--to=ssmeenk@freshdot.net \
--cc=linux-nfs@vger.kernel.org \
/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