On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote:
> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote:
> > Hi,
> > I have started to write a design page for 'Migrating existing
> > environments to Trust'
> > http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust
> > It shall cover https://fedorahosted.org/freeipa/ticket/3318 and
> > https://fedorahosted.org/freeipa/ticket/3979 .
> while working on a new version of the page with more details on design
> and implementation I came across the following problem. On the IPA
> server there should be a way for SSSD to deliver unmodified data (no
> view applied) or views other than the one for the IPA server to
> processes which delivers user and group data to other clients. This are
> mainly the extdom and the compat plugin of dirsrv.
> The two currently use standard glibc calls like getpwnam_r() to get the
> needed data from SSSD. While they can read the view objects form the
> LDAP tree there is no way to read the original data for users from
> trusted domains because it is only in the cache of SSSD.
> I'm looking for a way to allow SSSD to deliver the data without changing
> the protocol used by the NSS responder.
> One way I can think of is to use a new socket like
> /var/lib/sss/pipes/nss_noview and create a small library for the extdom
> and compat plugin to use the new socket. With this the plugin have to
> apply the views on their own if needed.
> Another way would be a new command for the NSS responder with two
> arguments, the view name (or empty for unmodified data) and a blob which
> contains the data for the corresponding request like e.g. getpwnam_r() or
> getgrgid_r(). Here the plugins have to use some new calls but all view
> processing can happen in sssd and the plugins can deliver the data
> A drawback in both cases is that the memcache cannot be used.
> If someone has suggestions for SSSD or other ways how to deliver user
> and group data to client with other views than the IPA server I'm all
Ok this one is hard to deal with in a way that will satisfy every
I think what we need to aim is simplicity and predictability at the
expense of flexibility.
What I mean is that freeipa servers should be allowed to only stick to
one view, the default view for external users.
And then the extdom plugin will be allowed to overlay a different view
for specific clients.
But the default view is the baseline, no special behavior.
If you need to 're'-override some attributes in specific views, so be
Simo Sorce * Red Hat, Inc * New York
Freeipa-devel mailing list