[SSSD] [PATCH] Let the PAM client send its PID

Sumit Bose sbose at redhat.com
Sun Sep 13 10:23:28 UTC 2009


On Sat, Sep 12, 2009 at 09:02:34PM -0400, Simo Sorce wrote:
> On Sat, 2009-09-12 at 10:11 +0200, Sumit Bose wrote:
> > On Fri, Sep 11, 2009 at 05:46:24PM -0400, Simo Sorce wrote:
> > > On Fri, 2009-09-11 at 17:10 +0200, Sumit Bose wrote:
> > > > Most of items are not mandatory at the protocol level. If e.g. the
> > > > remote host is not known to the client it is not sent to the server
> > > > and
> > > > the server complains if he really needs it, e.g. the user name.
> > > > 
> > > > I haven't put a check like 'if cli_pid==0 do not send to the server'
> > > > because as getpid(2) says "These functions are always successful.".
> > > > 
> > > > On the server side cli_pid is 0 if the client does not send a PID
> > > > item.
> > > > 
> > > > I think the way it currently works is the way your are expecting it to
> > > > work.
> > > 
> > > Will the unpacking function work is the client doesn't send the pid at
> > > all (ie it is an older client ?).
> > 
> > Yes, it will work. This was one of the main ideas why I have changed the
> > original protocol some time ago. Every item has an identifier. So it is
> > always clear for the unpacking function what the next item will be. If
> > one item is missing, it is just left empty (NULL,0) on the server side.
> 
> Oh I know the items are recognized by our code, but I am not sure that
> dbus_message_get_args() is as forgiving.
> Or does it just stop getting args when it sees DBUS_TYPE_INVALID even if
> there are more in the actual message ?
> 

Internally the cli_pid is always send, even if it is 0.

Nevertheless,

selfNACK

I have forgotten to put the size of the cli_pid into the protocol. This
might look a bit redundant, but if you have an older server and a newer
client the server does not know about the cli_pid item and how large it
might be. With the size it can jump to the next item on the wire and
continue working with items it knows about.

bye,
Sumit



More information about the sssd-devel mailing list