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

RE: Speak now, or...



Whoa there, Michael. Don't go so fast.

I do have a folder of all of the messages which have been sent to this   
list since it was created. (I even populated it with Andrew's copies for   
the messages prior to my joining it.)

In nowhere was there an "agreement". In fact, "agree" was referenced in   
only a few messages dated on 07/04/96 (if you discount the one message at   
04/29/96 by Andrew.) Do you want a copy of them?

The only agreement which seemed to have occured was that xlock should not   
mess with utmp because it does not start/stop a session.

So, Yes, I do have a problem with your proposed scheme.

I do not want login lying around on the system waiting for a shell to   
terminate. That is wrong. It goes against the way that I think of UNIX   
and, in my opinion, will only open up yet another hole that can result in   
strange race and deadlock conditions.

The present design of init running a program and that program terminating   
which causes init to restart it is still the best way.

There is no reason to keep login lying around just waiting for the event   
to occur. The present scheme of using rlogind, telnetd, and getty is   
quite good at the session management and I, for one, am not so willing to   
just abandon it for the sake of PAM.

PAM seems to work on the Sun platforms. It works without keeping login   
there. Perhaps you should go back and investigate what Sun does before   
you decide to change things so drastically.

 ----------
From:  Michael K. Johnson[SMTP:johnsonm@redhat.com]
Sent:  Wednesday, July 24, 1996 7:48 PM
To:  pam-list
Subject:  Re: Speak now, or...


Al Longyear writes:
>There is something that I don't quite understand here.
>
>You say that if login does authentication then it will use PAM. If it
>does not, then it won't. OK. That much is good.

No, that's not what I said.  I said that if it doesn't do authentication,
it will still open and close a session.

>However, login does not wait for the session to terminate. It execs the   
    

>shell which replaces the login program by the shell.

Not any more.  We've discussed this on the pam list already.  As we
agreed, a pamified login forks, execs, and waits.  Yes, it's not what
Unix has done since the beginning of time.  We do know that.  We are
now changing that.

>Therefore, if you are going to end the session, the work for ending the   
    

>session is performed by the starting logic of getty and not by login.
>Login starts the session. It does not end it.

That is not what we agreed upon a week or three ago on this list.



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