Hacker News Reader

Comment by JdeBP | Hacker News Reader

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.

View on HN

AIUI that is how it works on HURD today.

https://www.gentoo.org/news/2026/04/01/gentoo-hurd.html

> To log in, input login root, then use gnuhurdrox as the password

(Emphasis mine)

> 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.

Okay, so basically something like Windows's "Anonymous Logon" SID, which doesn't belong to the Authenticated Users group: it's the group that's normally associated with the default Write permissions; the Users group has only read-only access.

That sort of idea, yes.

I've just done some research and it looks like the Debin Hurd people did attempt to actually implement this. I just never heard about it. There was a 'login shell' and a 'nouser'. The latter had am empty set of IDs, and this case (optionally) switched to an extra set of rwx permission bits that existed specifically for determining 'nouser' access.

* https://groups.google.com/g/linux.debian.ports.hurd/c/2rCbPl...

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.

Yes, and under the covers some parts of Windows NT, notably server processes, do something akin to this; although its interactive login on a windowstation system follows the Unix model of the TCB doing the login dialogue and then spawning a user process running as the logged-in user.

That is how Lisp Machines worked.

Reply on news.ycombinator.com