[PATCH] winbind interface to extract SIDs from PAC

[Volker Lendecke]

On Tue, Jul 17, 2012 at 04:30:25PM +1000, Andrew Bartlett wrote:
> On Tue, 2012-07-17 at 08:21 +0200, Volker Lendecke wrote:
> > On Tue, Jul 17, 2012 at 01:22:05PM +1000, Andrew Bartlett wrote:
> > > I've still been thinking about this, and the primary change I would like
> > > to see from here is in what the interface aims to achieve (even if it
> > > does not totally at present).
> > > 
> > > That is, I would like the goal to be to return the full token as a SID
> > > list, not just the SIDs present in the PAC.  I know I said it was 'too
> > > hard' earlier in the thread, but I think we need to get this right -
> > > this is the most practical way for another application to obtain the
> > > fully expanded SID list.  As a start, we should at least add the
> > > boilerplate SID_NT_NETWORK, SID_NT_AUTHENTICATED and SID_NT_WORLD but we
> > > should work out a way to call the routines I suggested (as far as we can
> > > within the rules for winbindd).
> > 
> > wbcAuthUserInfo has the raw info3 struct without any
> > SID expansion, I would vote for the same with the PAC
> > extraction. Christof has a need now, I would really vote for
> > the simplified interface he needs.
> 
> The only reason wbcAuthUserInfo works is because the only caller I know
> of does substantial work to transform it into a useful thing.  Indeed,
> to me that is quite similar to the work being asked here.
> 
> I also think this answers the question better that Simo put as to why
> this isn't just an API call.  That is, adding a IPC call to do a
> structure parse seems like a licence workaround, while adding an IPC

What is so bad about a license workaround that fills a real
need? Do you really want people to re-implement the PAC
parsing just because we do not want to expose it in a
compatible manner?

> call to do complex internal database queries is instead a reasonable
> engineering solution that also happens to provide a licence boundary.
> 
> Christof,
> 
> So I am clear, what is your overall need here?  Rather than what code
> might do the task, can we step a layer up the stack for a moment, and
> discuss what exactly you are trying to achieve?

To avoid timezone issues, let me step in here. NFS ganesha
needs to expand the PAC to get a reliable list of user and
group IDs. To the best of my knowledge this is the only way
for authorization to work reliably. A member server has no
way to figure out the group list it was presented in the
PAC. NFS ganesha at this point has no interest in expanded
groups or other token elements like session keys etc.

How do you want ganesha to get this very simple query solved?

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de