----- 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. > 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@xxxxxxxxxx \__\/\/__/ IPA/Kerberos5 team /O /==\ O\ (;O/ \/ \O;) _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
