----- Original Message -----
From: "Simo Sorce" <ssorce(a)redhat.com>
To: "Niels de Vos" <ndevos(a)redhat.com>
Cc: gluster-devel(a)gluster.org, sssd-devel(a)lists.fedorahosted.org, "Vijay
Bellur" <vbellur(a)redhat.com>
Sent: Friday, November 7, 2014 2:42:50 PM
Subject: Re: [SSSD] memory cache for initgroups
On Fri, 7 Nov 2014 09:59:32 +0100
Niels de Vos <ndevos(a)redhat.com> wrote:
> On Thu, Nov 06, 2014 at 05:32:53PM -0500, Simo Sorce wrote:
> > On Thu, 6 Nov 2014 22:02:29 +0100
> > Niels de Vos <ndevos(a)redhat.com> wrote:
> > > On Thu, Nov 06, 2014 at 11:45:18PM +0530, Vijay Bellur wrote:
> > > > On 11/03/2014 08:12 PM, Jakub Hrozek wrote:
> > > > >On Mon, Nov 03, 2014 at 03:41:43PM +0100, Jakub Hrozek wrote:
> > > > >>On Mon, Nov 03, 2014 at 08:53:06AM -0500, Simo Sorce wrote:
> > > > >>>On Mon, 3 Nov 2014 13:57:08 +0100
> > > > >>>Jakub Hrozek <jhrozek(a)redhat.com> wrote:
[snip]
[1] IIRC Posix requires that the credentials set in the kernel at login
time are used throughout the lifetime of the process unchanged.
Right (except it's normally inherited from parent process, not login process directly)
... that's I was wondering whether the whole group information can be passed around
via shared memory (reducing the group lookup functions to
atomic_refcount+shared_mutex_lock+|memcpy()|+shared_mutex_unlock) so child
processes&co. can inherit it automagically without constant lookups.
This is
particularly important as a process may *intentionally* drop auxiliary
groups or even change its credentials set entirely (like root switching
to a different uid and arbitrary set of gids).
... don't forget the case of newgrp(1) with groups with passwords, e.g. a random user
can obtain an extra group membership when the matching group has a password... ;-/
You may decide this is not something you want to care about for
network
access, and in fact NFS + RPC_GSSSEC do es *not* do this, as it always
computes the credentials set on the server side at (GSSAPI) context
establishment time. Up to you to decide what semantics you want to
follow, but they should be at least predictable if at all possible.
The problem with GlusterFS vs. RPC_GSSSEC might be that GlusterFS tries to be stateless
whereever possible...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) rmainz(a)redhat.com
\__\/\/__/ IPA/Kerberos5 team
/O /==\ O\
(;O/ \/ \O;)