I agree with Simo. UNIX was designed so that group membership is set only
at session creation time. Linux mimicked that same approach.
So if this is a problem, it's bigger than sssd. Consider a local user
that's a member of a local group that confers additional privileges (like
the 'wheel' group). If that user is removed from that local group, any
active sessions still list his membership in that group. That indicates
it's not an sssd-specific problem.
BTW, if you totally delete that local group, the "id" command can no longer
output the textual name for that GID in the active session. But it still
insists the user is a member of that group -- even though the group
technically no longer exists. Again, that's because group membership is
set up at session creation time and then never changed thereafter. Until
the session ends.
Granted, this is a 50 yr old OS design -- back when companies had 3-4
computers max. Thus, it was easy for a sysadmin to jump on those 3-4
computers and terminate a user's sessions. Maybe this should be
revisited. But that's a much bigger re-design than just sssd.
On Wed, Feb 19, 2020 at 8:45 AM <patrick.hush(a)comcast.net> wrote:
This is NOT an OUD issue, it's not really and issue for sssd
Look at your sssd.conf, are you caching?
What is the time to live?
What does your pam auth for session section look like is sss optional or
Can you post your sssd.conf, pam.d/system-auth? (strip out the sensitive
> On February 19, 2020 at 12:25 AM Hristina Marosevic <
> I installed and configured SSSD with LDAP server OUD (Oracle Unified
Directory). Everything works fine so far, except for one thing which I
consider as a vulnerability.
> I just found out that there is a potential security hole which is the
old session of a user who lost his authorization.
> Generic example:
> User1 has to belong to the LDAP group sshUsers which is configured as an
access filter on the SSSD client in order to be authorized (after the
successfull authentication) for access to the remote linux machine, where
the SSSD client is installed.
> User1 is a member of the LDAP group sshUsers and logs in to the remote
> After the successfull login of the User1 to the remote linux machine,
its membership in the LDAP group sshUsers is removed i.e. User1 looses it
authorization to access the remote linux machine.
> What happens as a result is:
> 1. The active ssh connection od User1 to the remote linux machine which
was established before he lost his authorization is still active!!
> 2. User1 (after he lost his authorization) can not login to the remote
linux machine anymore - this is okay.
> Security hole - explained in 1.
> Can you please explain to me if there is a possiblity for SSSD to manage
the sessions, how to do that? If this is not possible (whn using OUD)
should it be proposed as a bug?
> Other than that, how is session managed on the OS layer?
> Thank you!
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines