why is /bin/login suid root on some systems?

why is /bin/login suid root on some systems?

Post by those who know me have no need of my nam » Thu, 29 Aug 2002 04:05:01



in comp.security.misc i read:

Quote:>My guess is that it was done this way so that dialup users wouldn't have to
>hang up and dial in again to get a new login prompt.  They could just type
>"login <username>".  The Trusted Path concept wasn't important to the
>original Unix designers, either.

>Don't ask me why they would need to use "login <username>" instead of "su -
><username>".  Maybe it predated the "su" command?

  exec login username

to save memory, instead of pushing down a level.  important on some of the
earliest systems.

also if you are `transferring' control to another person, a push via su
means that they can exit and resume control as the previous user, but an
exec of login means that control is irrevocably transferred.

--
bringing you boring signatures for 17 years

 
 
 

why is /bin/login suid root on some systems?

Post by Barry Margoli » Thu, 29 Aug 2002 04:17:34




Quote:>in comp.security.misc i read:

>>My guess is that it was done this way so that dialup users wouldn't have to
>>hang up and dial in again to get a new login prompt.  They could just type
>>"login <username>".  The Trusted Path concept wasn't important to the
>>original Unix designers, either.

>>Don't ask me why they would need to use "login <username>" instead of "su -
>><username>".  Maybe it predated the "su" command?

>  exec login username

>to save memory, instead of pushing down a level.  important on some of the
>earliest systems.

I think that many shells have "login" as a built-in that performs "exec
login".  If you really want to push a level you had to type \login or
/bin/login.  The tcsh(1) man page says:

     login   Terminates a  login  shell,  replacing  it  with  an
             instance  of /bin/login. This is one way to log off,
             included for compatibility with sh(1).

The builtin checks whether it's being run from a login shell, and reports
an error if not.  If you execute /bin/login directly, on Solaris 2.6 it
checks whether there's a utmpx entry for the current tty; if there isn't,
it assumes you're not in a login shell.

I don't think early versions had all these checks; they become more
necessary with the advent of window systems.

Quote:>also if you are `transferring' control to another person, a push via su
>means that they can exit and resume control as the previous user, but an
>exec of login means that control is irrevocably transferred.

So does "exec su username".

The main difference between su and login is that login updates databases
like utmp, so "who" shows the new user rather than the original login user.
If you push a login and then return from it, you'll end up as a phantom
user, because utmp will claim that no one is logged into that tty.

--

Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

why is /bin/login suid root on some systems?

Post by Ralf Fasse » Thu, 29 Aug 2002 21:04:54



| The builtin checks whether it's being run from a login shell, and
| reports an error if not.  If you execute /bin/login directly, on
| Solaris 2.6 it checks whether there's a utmpx entry for the current
| tty; if there isn't, it assumes you're not in a login shell.
|
| I don't think early versions had all these checks; they become more
| necessary with the advent of window systems.

Just being curious: why would it be necessary to check for a login
shell before exec login?  Any security related issues?  Or just that
`who' does report the wrong things?

R'

 
 
 

why is /bin/login suid root on some systems?

Post by Casper H.S. Di » Fri, 30 Aug 2002 02:06:46




>| The builtin checks whether it's being run from a login shell, and
>| reports an error if not.  If you execute /bin/login directly, on
>| Solaris 2.6 it checks whether there's a utmpx entry for the current
>| tty; if there isn't, it assumes you're not in a login shell.
>|
>| I don't think early versions had all these checks; they become more
>| necessary with the advent of window systems.
>Just being curious: why would it be necessary to check for a login
>shell before exec login?  Any security related issues?  Or just that
>`who' does report the wrong things?

Some stuff depends on getlogin(); I remember sending mail after doing
login in a subshell "(login friend)" and logging back out; the mail
still had my friend's name as "from" address.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

1. Using /bin/csh for root login on SCO Unix causes improper boot--why?

At work we have a 386 system (used for accounting) running SCO Unix.  I
changed the shell for root (in the /etc/passwd file), from '/bin/sh' to
'/bin/csh'.  Boy did this cause problems.  Everything works fine, until you
reboot the system.  While the system is coming up (e.g. starting cron, print
services, etc.) is starts display the /etc/motd (i.e. message of the day) file.
After the system finally comes up, if you look at the /etc/systemid file it
contains the contents of the /etc/motd file prepended to what was originally in
the /etc/systemid file, that is the /etc/motd file is in the /etc/systemid file
with the original value of the /etc/systemid file at the bottom.  Also, the
/etc/mnttab table is totally trashed, containing a lot of garbage that commands
like 'df' puke on.

On other Unix systems I have found that a lot of times the scripts in /etc that
are executed upon boot, don't contain the ":" or "!/bin/sh" at the top of them,
which tells them to execute using the Bourne shell; therefore, if they are
executed using the C-shell they crash.  I looked through quite a few of them
on the SCO Unix system, but they appeared to be okay.

Has anyone else experienced this problem or know why it happens?  Is there just
a badly formed script that I overlooked or what?

Your help is appreciated!!!

Bruce
--
Bruce M. Himebaugh                                          Voice: 216-484-3528
   PATHS: uunet!{ncoast,aablue}!fmsystm!bmhalh!bruce
          (NOTE: the system name "fmsystm" is with no "e", NOT "fmsystem")

2. add an NFS memory pool

3. Why does /bin/login and /usr/bin/newgrp not have setuid bit set?

4. Settings for Proview 768m?

5. suid root /bin/sh problem

6. NEWBIE: help shutting down gnome

7. Should /bin/ecs have SUID root???

8. ld: BRADDR error on alpha linux

9. suid root /bin/sh problem

10. Why Redhat does not make Xfree server suid root ?

11. why is xterm suid root?

12. why don't my suid root shell scripts work under Solaris 2.5?

13. Why is xterm suid root?