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.

Sign up for GitHub

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

Jump to bottom

SSSD must be able to resolve membership involving root with files provider #5170

Closed
pbrezina opened this issue May 20, 2020 · 1 comment
Closed

SSSD must be able to resolve membership involving root with files provider #5170

pbrezina opened this issue May 20, 2020 · 1 comment
Assignees
@pbrezina
Labels
Bugzilla Closed: Fixed Issue was closed as fixed.

Comments

@pbrezina
Copy link
Member

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 8): Bug 1794607

Description of problem:
With sssd, "getent group" miss a user whose primary group is root.

Version-Release number of selected component (if applicable):
RHEL8.1(sssd-common-2.2.0-19.el8.x86_64) or RHEL8.2
Beta(sssd-common-2.2.3-6.el8.x86_64)

How reproducible:
Often on RHEL8.1
Sometimes on RHEL8.2 Beta

Steps to Reproduce:
1. Install RHEL8.1 or RHEL8.2 Beta

2. Uncomment the following line in /etc/pam.d/su to implicitly trust users in
the "wheel" group.

# vi /etc/pam.d/su
...
auth            sufficient      pam_wheel.so trust use_uid


3. Add a user as primary group: root and supplementary group: wheel

# useradd -g root -G wheel user01


4. Run su as follows.

# su user01                     # *A
$ su
Password:                       # It's not supposed to.

*A "su user01" makes the following situation.
~~~
# grep wheel /etc/group
wheel:x:10:user01
# getent group wheel
wheel:x:10:
~~~

Actual results:

# getent group wheel
wheel:x:10:


Expected results:

# getent group wheel
wheel:x:10:user01


Additional info:

The following is a workaround.

# systemctl stop sssd
# rm -f /var/lib/sss/mc/*
@pbrezina pbrezina self-assigned this May 20, 2020
pbrezina added a commit to pbrezina/sssd that referenced this issue May 20, 2020
@pbrezina
files: allow root membership
3d9bebf 
SSSD design decision was to "never handle root" and we use uid=0 and gid=0 to indicate
various error states. root user and group is unconditionally added in negative cache.
This makes perfect sense for LDAP but introduced regressions in files provider
when compared to nss_files:

1) When a user is part of root group - the membership is not returned
2) When a user has root as primary group - the user is not returned and every other membership is broken.

The "never handle root" policy is basically kept, with few exceptions for files provider:
- it will not filter out root as group member if it is also files provider - solves 1)
- it will store user with gid=0 unless it also has uid=0 thus solving 2)

Direct request for root user or group will still not be handled.

Resolves:
SSSD#5170
@pbrezina pbrezina mentioned this issue May 20, 2020
Closed
pbrezina added a commit to pbrezina/sssd that referenced this issue Jun 23, 2020
@pbrezina
files: allow root membership
9838f7b 
SSSD design decision was to "never handle root" and we use uid=0 and gid=0 to indicate
various error states. root user and group is unconditionally added in negative cache.
This makes perfect sense for LDAP but introduced regressions in files provider
when compared to nss_files:

1) When a user is part of root group - the membership is not returned
2) When a user has root as primary group - the user is not returned and every other membership is broken.

The "never handle root" policy is basically kept, with few exceptions for files provider:
- it will not filter out root as group member if it is also files provider - solves 1)
- it will store user with gid=0 unless it also has uid=0 thus solving 2)

Direct request for root user or group will still not be handled.

Resolves:
SSSD#5170
pbrezina added a commit to pbrezina/sssd that referenced this issue Jun 23, 2020
@pbrezina
files: allow root membership
91d33fb 
There are two use cases that do not work with files provider:

1. User has primary GID 0:

This is fine by itself since SSSD does not store this user in cache and it is
handled only by `nss_files` so the user (`tuser`) is returned correctly. The
problem is when you try to resolve group that the user is member of. In this
case that the membership is missing the group (but only if the user was
previously resolved and thus stored in negative cache).

```
tuser:x:1001:0::/home/tuser:/bin/bash
tuser:x:1001:tuser

// tuser@files is ghost member of the group so it is returned because it is not in negative cache
$ getent group tuser
tuser:x:1001:tuser

// expire memcache
// tuser@files is ghost member but not returned because it is in negative cache
$ id tuser // returned from nss_files
uid=1001(tuser) gid=0(root) groups=0(root),1001(tuser)
[pbrezina /dev/shm/sssd]$ getent group tuser
tuser:x:1001:
```

**2. root is member of other group**

The root member is missing from the membership since it was filtered out by
negative cache.

```
tuser:x:1001:root

$ id root
uid=0(root) gid=0(root) groups=0(root),1001(tuser)
[pbrezina /dev/shm/sssd]$ getent group tuser
tuser:x:1001:
```

In files provider, only the users that we do not want to managed are stored
as ghost member, therefore we can let nss_files handle group that has ghost
members.

Resolves:
SSSD#5170
pbrezina added a commit to pbrezina/sssd that referenced this issue Jun 24, 2020
@pbrezina
files: allow root membership
efdb857 
There are two use cases that do not work with files provider:

1. User has primary GID 0:

This is fine by itself since SSSD does not store this user in cache and it is
handled only by `nss_files` so the user (`tuser`) is returned correctly. The
problem is when you try to resolve group that the user is member of. In this
case that the membership is missing the group (but only if the user was
previously resolved and thus stored in negative cache).

```
tuser:x:1001:0::/home/tuser:/bin/bash
tuser:x:1001:tuser

// tuser@files is ghost member of the group so it is returned because it is not in negative cache
$ getent group tuser
tuser:x:1001:tuser

// expire memcache
// tuser@files is ghost member but not returned because it is in negative cache
$ id tuser // returned from nss_files
uid=1001(tuser) gid=0(root) groups=0(root),1001(tuser)
[pbrezina /dev/shm/sssd]$ getent group tuser
tuser:x:1001:
```

**2. root is member of other group**

The root member is missing from the membership since it was filtered out by
negative cache.

```
tuser:x:1001:root

$ id root
uid=0(root) gid=0(root) groups=0(root),1001(tuser)
[pbrezina /dev/shm/sssd]$ getent group tuser
tuser:x:1001:
```

In files provider, only the users that we do not want to managed are stored
as ghost member, therefore we can let nss_files handle group that has ghost
members.

Tests are changed as well to work with this behavior. Users are added when
required and ghost are expected to return ENOENT.

Resolves:
SSSD#5170
pbrezina added a commit to pbrezina/sssd that referenced this issue Jun 24, 2020
@pbrezina
files: allow root membership
ceb0f9b 
There are two use cases that do not work with files provider:

1. User has primary GID 0:

This is fine by itself since SSSD does not store this user in cache and it is
handled only by `nss_files` so the user (`tuser`) is returned correctly. The
problem is when you try to resolve group that the user is member of. In this
case that the membership is missing the group (but only if the user was
previously resolved and thus stored in negative cache).

```
tuser:x:1001:0::/home/tuser:/bin/bash
tuser:x:1001:tuser

// tuser@files is ghost member of the group so it is returned because it is not in negative cache
$ getent group tuser
tuser:x:1001:tuser

// expire memcache
// tuser@files is ghost member but not returned because it is in negative cache
$ id tuser // returned from nss_files
uid=1001(tuser) gid=0(root) groups=0(root),1001(tuser)
[pbrezina /dev/shm/sssd]$ getent group tuser
tuser:x:1001:
```

**2. root is member of other group**

The root member is missing from the membership since it was filtered out by
negative cache.

```
tuser:x:1001:root

$ id root
uid=0(root) gid=0(root) groups=0(root),1001(tuser)
[pbrezina /dev/shm/sssd]$ getent group tuser
tuser:x:1001:
```

In files provider, only the users that we do not want to managed are stored
as ghost member, therefore we can let nss_files handle group that has ghost
members.

Tests are changed as well to work with this behavior. Users are added when
required and ghost are expected to return ENOENT.

Resolves:
SSSD#5170
pbrezina added a commit to pbrezina/sssd that referenced this issue Jun 25, 2020
@pbrezina
files: allow root membership
e063cb2 
There are two use cases that do not work with files provider:

1. User has primary GID 0:

This is fine by itself since SSSD does not store this user in cache and it is
handled only by `nss_files` so the user (`tuser`) is returned correctly. The
problem is when you try to resolve group that the user is member of. In this
case that the membership is missing the group (but only if the user was
previously resolved and thus stored in negative cache).

```
tuser:x:1001:0::/home/tuser:/bin/bash
tuser:x:1001:tuser

// tuser@files is ghost member of the group so it is returned because it is not in negative cache
$ getent group tuser
tuser:x:1001:tuser

// expire memcache
// tuser@files is ghost member but not returned because it is in negative cache
$ id tuser // returned from nss_files
uid=1001(tuser) gid=0(root) groups=0(root),1001(tuser)
[pbrezina /dev/shm/sssd]$ getent group tuser
tuser:x:1001:
```

**2. root is member of other group**

The root member is missing from the membership since it was filtered out by
negative cache.

```
tuser:x:1001:root

$ id root
uid=0(root) gid=0(root) groups=0(root),1001(tuser)
[pbrezina /dev/shm/sssd]$ getent group tuser
tuser:x:1001:
```

In files provider, only the users that we do not want to managed are stored
as ghost member, therefore we can let nss_files handle group that has ghost
members.

Tests are changed as well to work with this behavior. Users are added when
required and ghost are expected to return ENOENT.

Resolves:
SSSD#5170
@pbrezina
Copy link
Member Author

Pushed PR: #5171

  • master
    • 8969c43 - files: allow root membership

@pbrezina pbrezina added the Closed: Fixed Issue was closed as fixed. label Jun 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pbrezina pbrezina

Labels
Bugzilla Closed: Fixed Issue was closed as fixed.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@pbrezina