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.
This has stayed the case with the transition to Wayland: pressing Ctrl + Alt + F1 shows me the login screen, and Ctrl + Alt + F2 takes me back to the desktop.
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,
Is the entire utcc.utoronto.ca return 403 or just utcc.utoronto.ca/~cks? Maybe it's no longer common knowledge, but the ~string part typically means it's hosted in a way so individual unix users can somewhat control their own environments, sometimes with .htaccess files or other things, and adjust the responses from the web-servers somewhat.
Anyways, the point being that it might not be the university doing it, but an individual user. I guess the former would be kind of shitty, but the latter is maybe ok as individuals should be able to chose freely?
FWIW, both the domain at large + this specific URL seems to work fine for me in Spain.
Archive Today presently does not, and I'm getting hung up on Captcha tests trying to submit a bug report. Present broken archive: <https://archive.is/Nv9Ik>. If someone else could submit a "Bad Grab" report I'd appreciate it.
Edit: Re-reading the archived error page: ~cks specifically blocks Archive.Today, which is unfortunate.
(In general, check popular archive tools, such as the Internet Archive (above) or Archive Today, and post a working link rather than griping about individual site access issues.)
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.
And what would the effective permissions be? The access to any file would be done according to the "other" permissions bits or?.. Because if yes, then that'd be an interesting way to escape user-based quotas, you know.
I don't know. This was a very early description of how it would work that I read, a long time ago.
Thinking it through as a thought experiment, the way that I'd do it, a process with no credentials would not be able to open anything for write access and only a limited number of things for execute access, and be limited to a minimal amount of read access. One does not have to follow the POSIX model when one is introducing something so definitely outside of it as a process with no user/group IDs (perfectly fine as far as raw Hurd is concerned).
There was precedent for such ideas. On Novell Netware, MS/PC/DR-DOS clients could access only one server directory, containing the LOGIN program, until they had logged their machine on.
It would be very interesting if you could accumulate privileges by stacking logins. So `login a; login b` gave you both a and b privileges. `logout a` would drop a's privileges but keep b's.
> '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".
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.
GDM, at least, does: https://askubuntu.com/questions/910108/why-is-my-gdm-at-a-di...
This has stayed the case with the transition to Wayland: pressing Ctrl + Alt + F1 shows me the login screen, and Ctrl + Alt + F2 takes me back to the desktop.
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,
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.
Is the entire utcc.utoronto.ca return 403 or just utcc.utoronto.ca/~cks? Maybe it's no longer common knowledge, but the ~string part typically means it's hosted in a way so individual unix users can somewhat control their own environments, sometimes with .htaccess files or other things, and adjust the responses from the web-servers somewhat.
Anyways, the point being that it might not be the university doing it, but an individual user. I guess the former would be kind of shitty, but the latter is maybe ok as individuals should be able to chose freely?
FWIW, both the domain at large + this specific URL seems to work fine for me in Spain.
The "server" header says it's apache, so there could be a .htaccess file in that directory with the rules for that.
Trying to load any url under ~/cks/ starting with .ht gives a generic "Forbidden" response, and other urls like .foo give a "Not Found" error.
You got it, it’s just ~cks not letting me in. The University itself is still good.
1 reply →
Wayback has it: <https://web.archive.org/web/20260602133826/https://utcc.utor...>
Archive Today presently does not, and I'm getting hung up on Captcha tests trying to submit a bug report. Present broken archive: <https://archive.is/Nv9Ik>. If someone else could submit a "Bad Grab" report I'd appreciate it.
Edit: Re-reading the archived error page: ~cks specifically blocks Archive.Today, which is unfortunate.
(In general, check popular archive tools, such as the Internet Archive (above) or Archive Today, and post a working link rather than griping about individual site access issues.)
Works great for me :)
(Greetngs from germany)
Same here, my web browser shows as coming from 'Big Giant Firewall Company'....
You have to use "su" :)
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.
> One started a session with no user credentials
And what would the effective permissions be? The access to any file would be done according to the "other" permissions bits or?.. Because if yes, then that'd be an interesting way to escape user-based quotas, you know.
I don't know. This was a very early description of how it would work that I read, a long time ago.
Thinking it through as a thought experiment, the way that I'd do it, a process with no credentials would not be able to open anything for write access and only a limited number of things for execute access, and be limited to a minimal amount of read access. One does not have to follow the POSIX model when one is introducing something so definitely outside of it as a process with no user/group IDs (perfectly fine as far as raw Hurd is concerned).
There was precedent for such ideas. On Novell Netware, MS/PC/DR-DOS clients could access only one server directory, containing the LOGIN program, until they had logged their machine on.
It would be very interesting if you could accumulate privileges by stacking logins. So `login a; login b` gave you both a and b privileges. `logout a` would drop a's privileges but keep b's.
That is how Lisp Machines worked.