[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: sessions and utmp

Michael K. Johnson wrote:
> First of all, Sun (now) agrees with the rest of us that utmp handling
> doesn't belong in the session.  Second, Ted has pointed out some kinds
> of things that *do* make sense IRT sessions: the kerberos module would
> get and delete kerberos tickets, and there are also other possibilities
> such as mounting and unmounting a users home directory.

Actually, what Sun said is that they found it messy, but there is
still a place for a utmp module.

I think what I am having trouble with is a vague concern about how to
break existing applications into pieces that fit neatly into parts
that couple with PAM; if it were easy then there wouldn't be much to
discuss. And then, how to make use of the "added" features provided by
a PAM based system.

The important thing is that applications *are* ported. Sun has
indicated that they are not so strict about the use of session modules
so whoever is porting should do the minimum to get a working program
to work with PAM and do what it likes with session stuff. If it makes
sense (and is thus easy) to add session calls, then it should be
done. Otherwise I guess there is no problem to leave it
out... (Besides me mumbling and I'll keep that to myself for a while!)

I'll shut up and let those doing the work, do it.

> Could we define a session as the lifetime of a privilege granted
> by PAM?

The way I have been thinking of a session is "the lifetime of a
service offered to a user authenticated with PAM."

Care should be taken using the word "privilege", PAM is principally an
*authentication* system. Apart from the "group"-type of setcred
function (in which case the app must run at a privileged level to
work), it is the application that grants the privilege. This, like
other things, is a vague separation. But I think it is important to
stress that the application is the part of the partnership that does
the "granting".

> >Isn't it just one more freedom that comes with the flexibility
> >of using PAM?
> I think it's an example of license, not freedom.  IMHO, of course... :-)

I guess we can agree to differ.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []