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 > directly. > > 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 > ears.
Ok this one is hard to deal with in a way that will satisfy every possible user. 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 it. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
