Live data from Hacker News

Why GNU su does not support the `wheel' group (2002)

ftp.gnu.org

61–70 of 150 posts

Re: Why GNU su does not support the `wheel' group (2002)

#61
post #18

Earlier quoted context omitted.

You can disable direct root login and force users to login as their own account first. This way, any root login is tracked—you know who logged in as root, because they had to log in as their own account in order to run su.

In such case: sudo su, then. and let sudo verify that the user belongs to the group of allowed sudoers. No need for the password to the root account.

Objection: su is a very simple program that does (approximately) one thing. Meanwhile the sudoers(5) man page starts with an introduction to EBNF grammars.

I strongly prefer doas wherever it's available.

Re: Why GNU su does not support the `wheel' group (2002)

#62

A different reason why it's good that it doesn't support wheel: - it makes it smaller, less code which can go wrong - su isn't limited to "set user root" but wheel tends to be - it avoids having to handle many kind of subtle problems with group based permission handling in linux It's just not a bad idea to have a very minimalist program like su and then delegate all more complicated "acting as user" permission handli…

I don't think GNU has ever committed to any kind of minimalist philosophy. Have you seen the number of flags every command has? ls has almost the entire alphabet taken.

>I don't think GNU has ever committed to any kind of minimalist philosophy

So true. I remember early on when GNU was started, people in the project where saying and developing with something like this in mind (paraphrasing):

"Make sure it works and meet users needs, even if it is too heavy for current systems, the hardware will improve as time goes on"

And that came true, for example, emacs is a lite ballerina compared to current IDEs.

Re: Why GNU su does not support the `wheel' group (2002)

#63
post #15

Earlier quoted context omitted.

> It reminds me of something I'd read that one of the reasons modern capitalism is so borked is because the founding fathers weren't conceiving of things like "Amazon" existing, where one entity employs a staggeringly large number of employees. Or that a small number of companies would employ such a large percentage of workers. I'm not quite sure I buy that argument. They lived in the time of the East India Company,…

Yeah, there's definitely counterexamples. I thought of East India too. I really wonder what operating a huge company like that looked like in an era where the fastest way to transport messages was to have fresh horses pre-positioned every X miles and have someone gallop your message non-stop. I assume it was very different from Amazon employees peeing in bottles to avoid getting dinged for metrics.

> I really wonder what operating a huge company like that looked like in an era...

Lots of attempts to standardize procedures, etc., etc. - but East India agents far from home often had enormous latitude, and there were plenty of disasters and atrocities. (Not that either the British Government proper, or other European powers, were notably better. But they could certainly be worse - just look at the Spanish Conquest of the Americas, or the Belgian Congo.)

> ...the fastest way to transport messages was to have fresh horses pre-positioned ...

When there were enough short-but-important messages to be passed along a given route, they did have a far-faster-than-a-horse technology available - https://en.wikipedia.org/wiki/Optical_telegraph#India

Re: Why GNU su does not support the `wheel' group (2002)

#64

A different reason why it's good that it doesn't support wheel: - it makes it smaller, less code which can go wrong - su isn't limited to "set user root" but wheel tends to be - it avoids having to handle many kind of subtle problems with group based permission handling in linux It's just not a bad idea to have a very minimalist program like su and then delegate all more complicated "acting as user" permission handli…

suid bits are flawed and ideally should not exist. You should only be able to drop privileges. su/sudo should be replaced by ssh anotheruser@localhost (or simpler implementation with unix socket and without encryption, but the idea is the same).

You would not be able to change your password without suid.

I guess there are ways that sudo/doas could be adapted to implement passwd, chfn, chsh and friends, but the approach appears to have been chosen in the '70, and codified by POSIX.

How do you think these should be implemented?

Re: Why GNU su does not support the `wheel' group (2002)

#65
post #42

Earlier quoted context omitted.

What is special about the 'wheel' group and what is su even "checking" in the first place? Users who aren't in the wheel group aren't supposed to be able to become root, even if they have the password. Isn't it just supposed to switch user? And what are the implications of not-checking whatever it was supposed to check? Someone who steals the root password (say, by looking over the sysadmin's shoulder) would be able…

Native question: if you can `sudo`, can't you just `sudo bash`? What can you do with `su` that you couldn't do with `sudo bash`? Or is the wheel group not really about being able to sudo?

It's 'substitute user', not just 'super user'. With su you can impersonate any user.

Wheel users can do anything because (default) sudoers contains

  %wheel  ALL=(ALL)   ALL
https://unix.stackexchange.com/questions/152442/what-is-the-...

Re: Why GNU su does not support the `wheel' group (2002)

#66
post #64

Earlier quoted context omitted.

suid bits are flawed and ideally should not exist. You should only be able to drop privileges. su/sudo should be replaced by ssh anotheruser@localhost (or simpler implementation with unix socket and without encryption, but the idea is the same).

You would not be able to change your password without suid. I guess there are ways that sudo/doas could be adapted to implement passwd, chfn, chsh and friends, but the approach appears to have been chosen in the '70, and codified by POSIX. How do you think these should be implemented?

Just make a request to the service which runs under root to change password. Include necessary credentials (e.g. current password or its hash) and new password (or its hash). How this request will be authenticated is another matter, but there are plenty of ways to authenticate a request. Or may be there should be better ways if current ways are flawed.

My point that it does not have to be coded in the kernel as a dedicated mechanism to circumvent protection. Use any IPC channel to send a message to another process which already runs under root and accept those messages.

Re: Why GNU su does not support the `wheel' group (2002)

#67

Earlier quoted context omitted.

Reaction: How does that ideal play out, when a few kiddies start running fork bombs on a *nix system that Mr. Stallman wants to use?

This actually went on for many years. rms famously refused to secure his account @gnu.ai.mit.edu, and so the machine basically became an open shell server for every hacker in the world , ca. 1992. Lots of hijinks ensued, and it was usually not possible to do anything useful in that account, since it was usually broken or pwned in remarkable ways. But they were wild, fun times.

In a similar vein, EFF cofounder John Gilmore famously refused to secure his SMTP server at toad.com [1]. He believed SMTP should be open for all just like the old days, potentially making it basically an open relay for every hacker and spammer in the world. And so, he got into trouble with his ISP. Gilmore said the server was in fact rate-limited and the abuse potential was not as large as it appeared to be.

[1] https://en.wikipedia.org/wiki/John_Gilmore_(activist)#Activi...

Re: Why GNU su does not support the `wheel' group (2002)

#68

To be fair, that's ancient. This links to coreutils 4.5.4. I've got 9.1 installed. The current manpage says support for wheel is implemented in PAM.

I found this patch, which adds PAM support to coreutils 5: https://lists.gnu.org/archive/html/bug-coreutils/2003-04/msg...

It removes the section at the bottom of the man page, and has this addition to the source code comments:

    +#ifdef USE_PAM
    +
    +   Actually, with PAM, su has nothing to do with whether or not a
    +   wheel group is enforced by su.  RMS tries to restrict your access
    +   to a su which implements the wheel group, but PAM considers that
    +   to be fascist, and gives the user/sysadmin the opportunity to
    +   enforce a wheel group by proper editing of /etc/pam.conf
    +
    +#endif

Re: Why GNU su does not support the `wheel' group (2002)

#69

Earlier quoted context omitted.

This actually went on for many years. rms famously refused to secure his account @gnu.ai.mit.edu, and so the machine basically became an open shell server for every hacker in the world , ca. 1992. Lots of hijinks ensued, and it was usually not possible to do anything useful in that account, since it was usually broken or pwned in remarkable ways. But they were wild, fun times.

In a similar vein, EFF cofounder John Gilmore famously refused to secure his SMTP server at toad.com [1]. He believed SMTP should be open for all just like the old days, potentially making it basically an open relay for every hacker and spammer in the world. And so, he got into trouble with his ISP. Gilmore said the server was in fact rate-limited and the abuse potential was not as large as it appeared to be. [1] htt…

Hah! I don't doubt it, but amusingly that section of the article is blissfully free of citations or sources, just some original research. Cool stuff.

I used to do dumb stuff by telnetting to mail servers, back in the day. I think I really annoyed a few coworkers with that; one said he almost called CERT.

I think it was one of the earliest Cybersecurity realizations I had about how insecure the Internet really was, based as it was on blind trust among hosts that were supposed to have legitimate admins in control. I found that it was so easy to telnet to a mail server and feed it whatever you wanted, this must be the tip of the iceberg. And it was!

Post reply on HN