On Friday 05 Aug 2011 13:08:03 Stephen Gallagher wrote:
On Fri, 2011-08-05 at 09:07 +0100, Michael Gliwinski wrote:
> 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)
>
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).
...
The reason for UPGs and MPGs is to prevent accidental access leakage
when creating new files. By setting all users' primary group membership
...
I completely understand, the only reason I needed it is because a 3rd party
configured their application that way (informix based). I can always re-
arrange this setup like you said.
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.
...
> 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
By intentional, do you mean you wouldn't want such functionality?
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.
Understood. I naively thought it may be possible to use DNs from other
domains or some sort of fake DN in member fields in local database.
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.
Indeed, I'm aware that it works with /etc/group but I think it only works for
users. I was hoping to be able to use nested groups so things are independent
of e.g. staff changes.
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.
Ah, OK, I wasn't aware how the reverse links matter.
No worries at all, as I said I'm really happy with the robustness that SSSD
provides to the client-side of network auth/DS setup and things I mentioned
aren't actually something I've been able to do before no nothing's lost.
--
Michael Gliwinski
Henderson Group Information Services
9-11 Hightown Avenue, Newtownabby, BT36 4RT
Phone: 028 9034 3319
**********************************************************************************************
The information in this email is confidential and may be legally privileged. It is
intended solely for the addressee and access to the email by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail are subject
to the terms and conditions expressed in the governing client engagement leter or
contract.
If you have received this email in error please notify support(a)henderson-group.com
John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************