Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enable_virtual_user_private_groups feature request #3739

Closed
sssd-bot opened this issue May 2, 2020 · 0 comments
Closed

enable_virtual_user_private_groups feature request #3739

sssd-bot opened this issue May 2, 2020 · 0 comments

Comments

@sssd-bot
Copy link

sssd-bot commented May 2, 2020

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2698

  • Created at 2015-06-26 12:24:24 by richardgrainger
  • Closed as Duplicate
  • Assigned to nobody

Some Linux distributions recommend the use of the "User Private Group" (UPG) scheme, e.g. see: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/user-private-groups.html

Under the UPG scheme, every user created gets their own UPG with a GID corresponding to the UID of the user. The user's primary group is set as as the GID of the UPG.

From the above article: "Using user private groups makes it simpler and safer to manage file and directory permissions because umask defaults only have to restrict user access, not group access."

A generic instance of Microsoft Active Directory does not by default contain UPGs. Instead, on an SSS-enabled box, Active Directory users must have their primary group set to something else (typically "Domain Users"). This means that systems administrators must be more careful about the group ownership of files and folders. For instance home directories must be set with mode 0700 rather than mode 0770.

The feature request is for a new configuration option "enable_virtual_user_private_groups". By default this option should be set to "false" (disabled), but when enabled it will have the following effect:

  1. When a program makes a user-related API call (getpwid, getpwnam, etc) and this is handled by SSS, if no real POSIX primary group is set for the user, the user's primary group GID will be returned as the same value as their UID

  2. When a program makes a group-related API call (getgrgid, getgrnam etc), if the group requested does not actually exist in AD, but has the same name or ID (depending on the call) as an existing AD user, SSS will return a "virtual" group entry which has:

    • The same name as the user
    • the same uid as the user
    • exactly one member (the user with the matching name/UID)

With this feature added, sites which use an unextended Microsoft Active Directory as their authentication and directory source, can gain the benefit of the UPG scheme without making extensive changes to their Active Directory installation.

Comments


Comment from sbose at 2015-06-26 12:54:22

This RFE sounds quite similar to #1872, can you check if this is the case and close the ticket as duplicate.


Comment from richardgrainger at 2015-06-26 14:51:30

Yes, it is similar, although my request gives more detail and suggests how it could implemented.


Comment from richardgrainger at 2015-06-26 14:57:07

Actually, you can close this. I'll leave the information on #1872.


Comment from jhrozek at 2015-07-04 16:40:29

This is a duplicate of #1872.

resolution: => duplicate
status: new => closed


Comment from richardgrainger at 2017-02-24 14:28:04

Metadata Update from @RichardGrainger:

  • Issue set to the milestone: NEEDS_TRIAGE
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant