[Gluster-devel] [SSSD] memory cache for initgroups

[Simo Sorce]

On Mon, 10 Nov 2014 16:56:22 -0500 (EST)
Roland Mainz <rmainz at redhat.com> wrote:

> 
> 
> ----- Original Message -----
> > From: "Simo Sorce" <ssorce at redhat.com>
> > To: "Niels de Vos" <ndevos at redhat.com>
> > Cc: gluster-devel at gluster.org, sssd-devel at lists.fedorahosted.org,
> > "Vijay Bellur" <vbellur at 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 at 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 at 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 at 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.

The problem here is that the bricks run as a different user, there
isn't a user logged into the machine running the bricks, and the client
is generally on a completely separate machine.

> > 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... ;-/

Indeed, in theory the GlusterFS client should check the group list for
each new process that talks to it, and have a cache of "sessions"
associated to each process that have a "unique credentials signature"

> > 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...

It is indeed a problem, authentication/authorization and statelessness
often collide, a compromise needs to be found.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York