[PATCH] winbind interface to extract SIDs from PAC

[simo]

On Wed, 2012-07-18 at 18:46 +1000, Andrew Bartlett wrote: 
> On Tue, 2012-07-17 at 11:06 -0700, Christof Schmitt wrote:
> 
> > I looked at earlier notes about the discussion we had with
> > Ganesha developers. Their problem is that the principal in the
> > kerberos ticket does not contain the domain information. For
> > multi-domain environments Ganesha needs the user and group data
> > from the PAC since that already includes the domain information.
> 
> How does Ganesha get the user's groups at the moment?  I presume it
> calls initgroups or getgrouplist()?
> 
> > The original idea was to provide a winbind API call that
> > translates the user and groups in the PACs to the mapped unix
> > ids. While implementing this, i ended up calling sids_to_xids
> > internally in winbind, and moving that call out to the client
> > seemed like a simpler solution.
> > 
> > I think there is value in providing also the expanded SIDs or the
> > corresponding unix ids. The Ganesha developers might not be aware
> > of this behavior. 
> 
> This is what I've been trying to get at.  Indeed, up until now they and
> you haven't had to know that a call to initgroups() returns these groups
> as well.  In short, it 'just works', which is is a good property of an
> NSS interface. (See winbindd_getgroups.c and wb_gettoken.c for how this
> is handled). 
> 
> Of course it doesn't 'just work' for users from a foreign domain were
> winbindd has not seen the PAC, which is where we get to your desired
> extension. 
> 
> > I would suggest to include a winbind call now
> > to get the user ids from the PAC. Ideally this call can be
> > extended in the future when the infrastructure to get the
> > expanded ids is available. At the same time we can talk to the
> > Ganesha developers if they would also need the expanded list of
> > ids.
> 
> In the further investigation, if Ganesha uses initgroups() or
> getgrouplist() at the moment, then there is no reasonable choice but to
> do this properly (expand the local aliases) now, as to do otherwise
> would risk a regression (the answer won't be the same).
> 
> In short, what I suggest Ganesha needs is a call like getgrouplist(),
> but that takes a PAC as the first argument.  Then the output can be
> treated in the same way, but the results will be more complete, because
> the PAC will have been consulted.

It would be saner to have a call to prime winbindd cache with a PAC, and
then just use the normal initgroups calls.
No need for special interfaces for getgrouplist or similar, you really
want to prime the system so all processes can see the right answers.
That of course means you need to fully trust Ganesha to 'pollute' the
winbindd cache.

Incidentally I am working on a fix for the problem of trusting random
services on a machine, in part also to be able to trust PAC contents w/o
fully trusting the services themselves.

That effort is called gss-proxy (https://fedorahosted.org/gss-proxy/).

I would like to have a standard winbindd call that will trust gss-proxy
(and only the gss-proxy) process to pass in a PAC and fully trust it.

We have code for such an interface with the sssd daemon already.

> The implementation will be quite similar to wb_gettoken() (it could be
> an optional behaviour of that call), except it would skip
> LookupUserGroups and only call LookupUserAliases.
> 
> I hope this clarifies my concerns, and explains why I think simple PAC
> parsing isn't enough for this interface. 

To be honest, whether it is good enough or not really depends on the
local machine configuration. Local groups are usually unnecessary for
NFS serving, only the domain groups really matter. However if the
machine is also a client they may be useful for other processes.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>