linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Simo Sorce <simo@redhat.com>
Cc: David Howells <dhowells@redhat.com>,
	keyrings@linux-nfs.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
	linux-nfs@vger.kernel.org, krbdev@mit.edu,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches
Date: Thu, 01 Aug 2013 14:55:57 -0400	[thread overview]
Message-ID: <51FAAF3D.3010806@fifthhorseman.net> (raw)
In-Reply-To: <1375381798.15733.207.camel@willson.li.ssimo.org>

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

On 08/01/2013 02:29 PM, Simo Sorce wrote:

> It's called 'abstraction' :-)

Good, I like abstraction :)

>> 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?
> 
> Just as a user can add data into a shm segment ?
> Is there any difference ?

I guess this raises the question from a different perspective: if the
kernel already supports arbitrary shm segments, filesystem locations,
etc, which can be used for storing/passing opaque bytestrings between
different parts of userspace, what advantages do we gain from having
this new specific mechanism in the kernel?  Why couldn't those parts of
userspace just rely on already-existing mechanisms instead of
introducing this new interface?

Again, i'm not trying to say it's a bad idea; there's probably a
big-picture piece of the puzzle that i don't see that makes this all
obvious.  i just want to understand what it is.  Thanks for your
explanations!

Regards,

	--dkg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1027 bytes --]

  reply	other threads:[~2013-08-01 18:56 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
2013-08-01 18:29     ` Simo Sorce
2013-08-01 18:55       ` Daniel Kahn Gillmor [this message]
2013-08-01 19:10         ` Simo Sorce
2013-08-02 17:50       ` David Howells
2013-08-01 23:09   ` Eric W. Biederman
2013-08-02 13:55   ` Jeff Layton
2013-08-02 14:16     ` Simo Sorce
2013-08-02 20:20     ` Nico Williams
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 17:00   ` David Howells
2013-08-02 17:05   ` David Howells
2013-08-02 17:44     ` Eric W. Biederman
2013-08-02 17:12   ` David Howells

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=51FAAF3D.3010806@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 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).