FRESH

Hacker News

When su replaced login for becoming another Unix login

56 points by ankitg12

by jancsika

1 subcomments

Hijacking this post for my own selfish curiosity:
Since Linux has these built-in ttys, why wasn't login done like this:
1. put a bare-bones x11 instance on the "login" tty with the necessary graphical/DE crap for login prompt
2. if the user enters the correct credentials in the graphical crap, switch the user to another tty and spawn a new x11 instance there for their graphical user environment/DE
That way you could use the "login" tty for the login prompt, accessibility apps, screensaver, win-at-space-invaders-to-login, etc. Then if stuff crashes at any point during the login attempt it just falls back to an empty tty rather than a user session or whatever.

by pitched

5 subcomments

The site is returning Forbidden for me and they seem to have also blocked archive.* sites. A bit of a mean thing for a public university to do.

by stronglikedan

0 subcomment

> 'superuser', likely the source of the 'su' command name
Hmmm, interesting. I always figured it stood for (s)witch (u)ser, but didn't know that "at the time it was only used to let you become root".

by lanycrost

1 subcomments

Always like to read history of operating systems and it's evaluation. As expected *BSD still following the standards unlike the linux :D
> As you might expect, all of the modern versions of su across Linux and the free BSDs support starting a login shell (cf the normal Linux su (also), FreeBSD su(1), NetBSD su(1), and OpenBSD su(1)). On Linux and OpenBSD, login isn't setuid root and so can't be used from a regular shell environment to become a new user; your only option is su. On FreeBSD and NetBSD,

by JdeBP

4 subcomments

One interesting idea, never realized that I know of, was for Hurd. The idea was that 'login' would be a simple utility program. One started a session with no user credentials, and ran 'login' as a command to add credentials to already running processes.
This was not at all how Unices worked, of course, which is likely why it never happened. On Unices it would have needed some sort of shared process credentials structure that could be augmented in place by a privileged process. On the Hurd, it would have required an extra method implemented by the auth server.
On my machines, login is not run any more. It's just a PAM client that provides a very dumb paper-compatible cooked mode terminal user interface, after all. I thought for a long time about writing a PAM client that had a better full screen TUI interface that assumed (gasp!) video terminals. So eventually I did just that.