auto_private_groups -- How does it work?

[Patrick Goetz]

There was a discussion on another list involving how to use sssd for 
authentication on an HPC cluster, and the issue of auto_private_groups 
came up.

I realized I have no idea how this works.  I know sssd keeps the GID 
(obviously known immediately from the UID) on the local host, but what 
is stored as the primary group for such files on the fileserver?  Let's 
say my UID is 1562224688.  How does the file server distinguish between 
files that are supposed to have the GID 1562224688 vs the ones set to, 
say, 1007000513 ?

Also, does this mean that sssd short circuits group authorization requests?

[Sumit Bose]

Am Thu, Sep 16, 2021 at 12:22:57PM -0500 schrieb Patrick Goetz:
> There was a discussion on another list involving how to use sssd for
> authentication on an HPC cluster, and the issue of auto_private_groups came
> up.
>
> I realized I have no idea how this works.  I know sssd keeps the GID
> (obviously known immediately from the UID) on the local host, but what is
> stored as the primary group for such files on the fileserver?  Let's say my
> UID is 1562224688.  How does the file server distinguish between files that
> are supposed to have the GID 1562224688 vs the ones set to, say, 1007000513
> ?

Hi,

with auto_private_groups SSSD will set the primary GID of the user to
the same numerical value as the UID of the user and move the original
primary group to the secondary groups. So there should be no difference
with accessing existing files because the user is still a member of the
orignal primary group.

When creating a new file it will be owned by default by UID 1562224688
and GID 1562224688. This is one of the main purposes of
auto_private_groups, to restrict the permission of freshly created files
by default. Depending on the umask setting a new file might be initially
only accessible by the user creating it. If more users should be able to
access it, thes permissions should then be changed explicitly, e.g. by
changing the group of the file or, even more elegant, by setting
suitable ACLs.

HTH

bye,
Sumit
> Also, does this mean that sssd short circuits group authorization requests?
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail].o...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure