On Thu, 2005-01-06 at 20:27 -0500, Steve Grubb wrote:
On Thursday 06 January 2005 19:42, Serge Hallyn wrote:
> I'm testing it by hacking auditctl.c to do an execl("/bin/sh",
> "/bin/sh"); if it was called on a -L. Before the "auditctl -L
25,ab" my
> loginuid is -1, after (on, say, a "auditctl -m cd") it is 25. Without
> the patch, it is always -1.
That's what I noticed and made me say I didn't think it was working right.
> Is that (-1 default loginuid until PAM sets it) the desired behavior?
If there is no logins, there's nothing to *set* the user ID. The number
returned needs to be fictional so its not mistaken for root or a real user.
But -1 isn't a fictional UID. There is no number within the uid_t space
which is reserved for your purposes to mean 'no user specified'.
It's been suggested that perhaps we could use the kernel's key
management facilities for this. By attaching a key of a certain type to
the session keyring, we get to set it _synchronously_, and we also have
an unambiguous indication of its _absence_.
David, can a process ever override its session keyring and elect to use
another? That could be a problem -- this has to be immutable after it's
set at login time, I believe.
--
dwmw2