From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: David Howells <dhowells@redhat.com>
Cc: keyrings@linux-nfs.org, linux-nfs@vger.kernel.org,
krbdev@mit.edu, "Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
linux-kernel@vger.kernel.org, simo@redhat.com,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH 2/2] KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches
Date: Thu, 01 Aug 2013 13:54:20 -0400 [thread overview]
Message-ID: <51FAA0CC.7010106@fifthhorseman.net> (raw)
In-Reply-To: <20130801173902.28023.68819.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: text/plain, Size: 975 bytes --]
On 08/01/2013 01:39 PM, David Howells wrote:
> The uid is -1 or the user's own UID for the user's own cache or the uid of some
> other user's cache (requires CAP_SETUID). This permits rpc.gssd or whatever to
> mess with the cache.
Is the goal here eventually to be able to avoid the upcall to rpc.gssd
entirely? It seems a little bit roundabout to have the kernel call up
into userspace for the credentials, only to talk to a process which then
calls back into the kernel for something that the kernel has already
well-defined internally.
It seems like a non-privileged user could use this to store arbitrary
data in this keyring as a way of hiding what would otherwise be
filesystem activity or using it for some sort of odd/sneaky IPC
mechanism. Is this an intentional side effect?
Sorry if these are obvious questions. feel free to point me to
already-documented answers if they exist.
Thanks for all your work on this!
Regards,
--dkg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1027 bytes --]
next prev parent reply other threads:[~2013-08-01 18:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-01 17:38 [RFC][PATCH 0/2] KEYS: Kerberos caching support David Howells
2013-08-01 17:38 ` [PATCH 1/2] KEYS: Implement a big key type that can save to tmpfs David Howells
2013-08-02 20:49 ` Nico Williams
2013-08-02 20:50 ` Nico Williams
2013-08-08 14:46 ` David Howells
2013-08-09 16:24 ` Nico Williams
2013-08-01 17:39 ` [PATCH 2/2] KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches David Howells
2013-08-01 17:54 ` Daniel Kahn Gillmor [this message]
2013-08-01 18:29 ` Simo Sorce
2013-08-01 18:55 ` Daniel Kahn Gillmor
2013-08-01 19:10 ` Simo Sorce
2013-08-02 17:50 ` David Howells
2013-08-02 17:12 ` David Howells
2013-08-01 23:09 ` Eric W. Biederman
2013-08-02 17:00 ` David Howells
2013-08-02 17:05 ` David Howells
2013-08-02 17:44 ` Eric W. Biederman
2013-08-02 13:55 ` Jeff Layton
2013-08-02 14:16 ` Simo Sorce
2013-08-02 16:53 ` David Howells
2013-08-02 17:00 ` Simo Sorce
2013-08-02 17:02 ` David Howells
2013-08-02 17:13 ` Jeff Layton
2013-08-02 20:20 ` Nico Williams
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=51FAA0CC.7010106@fifthhorseman.net \
--to=dkg@fifthhorseman.net \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=keyrings@linux-nfs.org \
--cc=krbdev@mit.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=serge.hallyn@ubuntu.com \
--cc=simo@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.