7:08 a.m.
On Fri, 2011-08-05 at 09:07 +0100, Michael Gliwinski wrote:
Hello all,
I have a couple of questions about the SSSD local domain, hope you'll be able
to shed some light.
I realise the local domain is currently mostly intended for testing, I also
get the impression (from searching the archives) that at some point it was
meant to be more than that, however I can't find details. I have a couple of
use-cases where the local domain would be rather useful, but I'm encountering
some problems.
1) When a user is created a private group is automatically created too,
however you can't seem to add another user into that group. Is this by design
or a bug? (I've one case where I need to be able to do this)
# sss_useradd test0
# sss_useradd test1
# sss_usermod -a test1 test0
Could not modify user - check if group names are correct
The automatically created group isn't a group in the traditional sense.
It's something that we call a Magic Private Group (MPG) as opposed to
the traditional User Private Group (UPG).
It's a special, truly private group that ONLY contains the matched user.
The idea behind UPGs was always that they were supposed to be truly
private. Adding a second user to a single UPG was a violation of the
intent. We created MPGs in the SSSD as a means of enforcing this rule.
The reason for UPGs and MPGs is to prevent accidental access leakage
when creating new files. By setting all users' primary group membership
to their private group, it ensures that all files they create are
private to themselves unless they choose to change the group (or grant
access to all users).
So what you really want to do here is create a new group and add both
users to it and then use that group in file/access permissions where
appropriate.
2) Cross domain memberships - that would be very useful to me. Specifically
being able to add both local users and groups (i.e. /etc/passwd, /etc/group)
and LDAP users and groups to a group in SSSD local domain.
At the moment this doesn't work as sss_usermod/sss_groupmod complains it
cannot find user/group in local domain.
Are there any plans to have such functionality in SSSD local domain (esp. the
2nd point)?
No, this is actually pretty much intentional. We have a number of
reasons for wanting to keep identity domains separate. From a technical
standpoint, right now we can't manage this because all domains maintain
their own separate cache database. There's no way to create a linkage
between groups in separate domains.
It's probably not an optimal answer for you, but it's possible to
use /etc/group for this purpose. Users added to a group in /etc/group
can be from any domain (because of the way that glibc handles things).
But this is a limitation of the SSSD local provider.
The way our cache works is by keeping user and group entries in an
LDAP-like local database. This database maintains a list of forward and
reverse links between groups and members of those groups. Since users
from other domains aren't located in the same database, we can't create
these forward and reverse links. Without those links, we can't
accurately identify group memberships among nested groups. These are not
insurmountable challenges, but the amount of work (and rewrites to the
cache) far exceed the value as we see it.
PS. many thanks for the great software, I started rolling out on our servers
and all the problems we had before with nss_ldap+pam_krb5+nscd are now gone!
We're glad to hear it!