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

[Roland Mainz]

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

> 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 at redhat.com
  \__\/\/__/  IPA/Kerberos5 team
  /O /==\ O\  
 (;O/ \/ \O;)