On Mon, 10 Nov 2014 16:56:22 -0500 (EST) Roland Mainz <rmainz@xxxxxxxxxx> wrote: > > > ----- Original Message ----- > > From: "Simo Sorce" <ssorce@xxxxxxxxxx> > > To: "Niels de Vos" <ndevos@xxxxxxxxxx> > > Cc: gluster-devel@xxxxxxxxxxx, sssd-devel@xxxxxxxxxxxxxxxxxxxxxx, > > "Vijay Bellur" <vbellur@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
