john@sol1.UUCP (john) (11/19/85)
I would appreciate someone filling me in on the advantages/disadvantages
of running login setuid to root. BTW our login forks, not execs the
login shell. (for accounting purposes).
[ Take what I say in a different way ]
[ and it's easy to say ]
[ that this is all confusion ]
John Korsmeyer @ THE SOLUTION
EMAIL: {akgua,ihnp4}!sol1!johnstephen@dcl-cs.UUCP (Stephen J. Muir) (11/25/85)
In article <380@sol1.UUCP> john@sol1.UUCP (John Korsmeyer) writes: >I would appreciate someone filling me in on the advantages/disadvantages >of running login setuid to root. BTW our login forks, not execs the >login shell. (for accounting purposes). The only disadvantage is that a user can't type "login other-user". They would have to logout first. -- UUCP: ...!seismo!mcvax!ukc!dcl-cs!stephen DARPA: stephen%comp.lancs.ac.uk@ucl-cs | Post: University of Lancaster, JANET: stephen@uk.ac.lancs.comp | Department of Computing, Phone: +44 524 65201 Ext. 4599 | Bailrigg, Lancaster, UK. Project:Alvey ECLIPSE Distribution | LA1 4YR
nick@inset.UUCP (Nick Stoughton) (11/27/85)
In article <380@sol1.UUCP> john@sol1.UUCP (John Korsmeyer) writes: >I would appreciate someone filling me in on the advantages/disadvantages >of running login setuid to root. BTW our login forks, not execs the >login shell. (for accounting purposes). If login is not setuid root, then it will fail to setuid to the person logging in, unless perchance it was root who called login. This means that calling login when you ARE logged in (and I don't understand the need to fork) will fail unless you are logging in as yourself, or you were logged in as root. Also, login needs to write to protected files (e.g. /etc/utmp). NOTE forking will probably mean that /etc/utmp gets screwed up ("who am i" when you log out, and revert to the original user, will be WRONG). -------- Nick Stoughton nick@inset.co.uk nick@inset.UUCP ...!ukc!inset!nick