[HN Gopher] Why GNU su does not support the `wheel' group (2002)
___________________________________________________________________
Why GNU su does not support the `wheel' group (2002)
Author : cdrt
Score : 80 points
Date : 2023-08-18 14:03 UTC (8 hours ago)
(HTM) web link (ftp.gnu.org)
(TXT) w3m dump (ftp.gnu.org)
| IshKebab wrote:
| This sounds like a protest against someone not giving him the
| root password. A stupid protest.
| pram wrote:
| Does this mean that RMS is ideologically opposed to sudo?
| nine_k wrote:
| It shows how old is that, and how things changed.
|
| Back in the day, it was about multiple OS users on one big
| machine, maintained by a university or a corporation.
|
| Now I'm the only human user of my several machines. I have more
| than one interactive user account on some of them. I put these
| accounts to the wheel group, to avoid ever using a root password.
| (Void Linux has it pre-configured in /etc/sudoers.)
| jml7c5 wrote:
| Yes, Unix was designed to protect users from each other but the
| modern need is to protect applications/invocations from each
| other. It is unfortunate that Unix wasn't really designed for
| the modern use case.
|
| Basically https://xkcd.com/1200/
| fsflover wrote:
| The solution is to use https://qubes-os.org. My daily driver,
| can't recommend it enough.
| jzb wrote:
| It's one of those things I keep thinking I'd like to try
| but actually implementing it seems like it'd be a huge pain
| in the posterior at first.
|
| Am I wrong about that?
| fsflover wrote:
| Probably depends on the hardware. See this:
| https://forum.qubes-os.org/t/community-recommended-
| computers....
|
| Upd: yes, also there is no GPU acceleration in the VMs.
| nine_k wrote:
| It's mostly a huge pain in the GPU, unless you only need
| the basics.
| bee_rider wrote:
| Qubes is one of those things that, I think, everyone knows
| is better but it seems just far enough away to not want to
| change.
|
| How big of a change is it? If you are, say, a Linux
| terminal native can you just pick up and run?
| invalidator wrote:
| Mostly yes. Your applications run in a standard Linux
| environment and if you pop up a terminal, hey, it's your
| favorite distro and it works.
|
| There's some learning curve for features which exist for
| valid reasons, especially around communicating between
| domains. For instance, copy-and-paste between qubes
| requires extra steps. Plugging in a USB keyboard or mouse
| doesn't just work - you have to authorize it first (just
| click the OK button using a PS/2 mouse, or laptop's
| touchpad). You have to learn how to move files between
| qubes. USB drives, cameras, and microphones aren't
| globally available to all applications - you have to
| attach them to a qube first. You can install software
| using apt-get inside a qube, but it won't persist across
| reboots - you have to update the OS template.
|
| I _want_ those extra steps and complications - they are
| features, not a bugs! The first few days you 'll be
| looking things up in the FAQ. After that it's pretty
| easy.
|
| There are a few sore points that don't go away. You don't
| get GPU acceleration in your web browser, so rendering is
| slower. Gaming is not an option. Your application qubes
| live behind a firewall qube, so things that require
| network broadcast like Chromecast won't work. Those are
| fine for me but not for everyone.
| fsflover wrote:
| All software runs in Linux VMs, so it is practically the
| same as running several Linux operating systems with a
| nice UI.
| nine_k wrote:
| You would feel at home more as a cloud native, because
| everything runs in its own VM, spun up and down on
| demand.
| markstos wrote:
| Qubes is enough of a pain to use that another OS project
| started to try to take the concept and make it more
| usable:
|
| https://spectrum-os.org/
|
| Doing so has proved hard and slow so far, and Spectrum
| hasn't had a usable release for the masses yet.
| dooglius wrote:
| > Initial versions of Spectrum will have the user be
| responsible for writing Nix code for each application and
| resource, and the combinations they make between them.
|
| As a qubes user, I think this is interesting but it
| definitely does not sound more usable.
| acheong08 wrote:
| I tried it for a week. Feels like overkill so I instead
| went for Fedora Silverblue & have everything in isolated
| podman containers.
|
| Of course, I'm not being targeted by the state so my threat
| model is much lower.
| fsflover wrote:
| It might be an overkill if you need too big efforts to
| switch. I did not feel that way. The independent VMs for
| different workflows even helped to organize my work.
| throwthat1 wrote:
| Everyone is somewhat targeted by the state already...
| Just not at a pin point level yet.
| TillE wrote:
| This is why I'm still hopeful that capability-based
| microkernels are the future. They simply fit modern security
| needs far better than hacky sandbox solutions on top of the
| same old operating systems with coarse permissions.
| cookiengineer wrote:
| The irony behind it is that one could argue that we are using
| UNIX wrong, because technically each program should run as
| its own user with its own groups. Which is what apparmor and
| firejail/sandboxes kind of want to embrace but in practice
| people just care too less.
| dathinab wrote:
| the problem is "just that" is not good enough
|
| because programs often to need to have part of the
| capabilities of the user which started them, just a very
| well controlled subset of them, something which the UNIX
| model can't properly represent (through you can hack it on-
| top of it)
|
| There is also the problem of having by default "owner-user
| owner-group other" as permission sets for files and
| executable. This works if others is "other humans"
| (assuming it does work, security issues on shared systems
| based on that where not uncommon). But this works much less
| if you want to protect users from rogue programs because
| then "other" tends to be far to permissive.
| derefr wrote:
| Process owned by human-user fork(2)s and then exec(2)s
| suid program owned by program-user; program owned by
| program-user then does most of the work; but calls back
| over a domain socket to program owned by human-user to
| get it to do things on the program-user's behalf.
|
| Picture: local DB client, remote DB server. Server can
| stream a file to the client for the client to write to
| disk. "On the same machine, as a different user" is just
| the trivial case of "over the network."
| jcrawfordor wrote:
| This doesn't actually provide the benefit of application
| isolation though; if the software is malicious or
| vulnerable the as-user component could be as well.
| Remember that the biggest use case for application
| isolation is untrusted applications. Essentially any
| setuid-based approach to isolation requires a trusted
| developer using very good practices to remain secure, and
| that's why it's faded away.
| atahanacar wrote:
| If everything is a file, and files can have permissions,
| then you can simply allow the "program user" access to
| those files using groups.
| jcrawfordor wrote:
| The group model is far too inflexible to make this
| realistic... A file can only have one group, and people
| use more than one application. ACLs are available on
| Linux (although seldom used) and help to address this
| problem, but the ergonomics are very poor. Since ACLs
| don't address the issue of syscalls, IPC other than file
| based, etc., It hasn't really made sense to make them the
| focus or application isolation efforts. The kernel
| namespacing and capabilities features are a lot more
| attractive for this use and are more similar to the
| historic approach of chroot... But the tools still aren't
| great.
| colonwqbang wrote:
| Maybe on the server/desktop side of things. In embedded
| Linux the "user per app" scheme is very useful and is
| embraced.
| rollcat wrote:
| The issue with implementing that on traditional UNIX
| systems is that only root can impersonate another user.
| (Mechanisms such as su/sudo are achieving their goal
| through a setuid bit, and implement a policy using
| executable code in user space, which historically hasn't
| been without its own share of bugs.)
|
| Next problem will be sharing data between programs that
| legitimately need to do so; if I had an _emacs user that
| owned my source code, how do I make it non-painful for the
| _gcc user to read the source and write the resulting
| executables (which would end up in a directory owned by
| _emacs)? What about git, various preprocessors/generators,
| formatters, linters?
|
| You'd have to step out of the traditional UNIX authn/authz
| model to effectively implement that. It's what various
| security-focussed OS's have been doing for a while anyway;
| e.g. OpenBSD implements unveil, which "hides" entire
| branches of the VFS tree. For example, if git has no
| business reading or writing files outside of the currently
| operated on repository, it can restrict itself very early
| in the process life - before proceeding to perform any of
| the "tricky" operations that are the common sources of
| security bugs.
| not2b wrote:
| That's what Android does: each app runs as a different
| user.
| ilyt wrote:
| Only sounds like "irony" if you don't understand problem.
|
| The problem is not isolation or lack of it. The problem is
| that app require complex set of permissions for both users
| files and other apps.
|
| App might want to send notification to notification daemon.
| But app should not be able to pretend to be another app,
| whether by name or icon. And good luck trying to stop
| malicious app from just making same/similar enough icon and
| spelling Firefox with some fancy UTF characters to go
| around it.
|
| And that's pretty simple case! And already very hard on
| kernel/OS level to solve. Now look at files.
|
| You might want to allow graphical editor to open any
| graphical file, regardless of location.
|
| You might want to allow that same editor to only edit some
| of them.
|
| But for browser, you might want to allow saving _new_
| files, but not editing /rewriting existing ones, because it
| is not an editor, and should have no business editing the
| files.
|
| Or, allow browser tab browsing certain URL (say, web image
| editor) to modify the files, but not the image sharing
| webpage that only needs to read the file.
|
| Now we not only have insanely granular permissions per app,
| the different actions from "app" (web browser is basically
| container for multiple applications at that point) also
| need different permissions.
|
| It has nothing to do with "unix bad", or "unix wrong", to
| actually separate the applications without hardships on the
| user (like fucking with permissions every time one app
| needs to touch files of another app) is just very very hard
| Someone wrote:
| > You might want to allow graphical editor to open any
| graphical file, regardless of location.
|
| More likely, you want to temporarily give them permission
| to specific files you indicate. A graphical editor
| doesn't have reason to read any file that the user didn't
| explicitly picked for editing/viewing.
|
| That's how Mac OS works nowadays (possibly except for the
| 'temporarily'; I don't know the details): applications
| can only open files that the user selected in the system
| file open dialog. That runs in a separate process and
| opens up an app's sandbox to allow access to the file the
| user selected.
| seanw444 wrote:
| It seems like the obvious solution. Users are protected
| from one another in Unix, applications need to be protected
| from each other, therefore applications must be users.
| jandrese wrote:
| Unix doesn't make it easy for an unprivileged user to
| switch to a different user account for just one app though.
| Plus it gets more complicated when your application wants
| to save something to the disk so it can be accessed by a
| different application.
| regularfry wrote:
| "More complicated" but not by much. That's where groups
| come in.
| heisstupid wrote:
| What a great example of how slavish devotion to an ideology makes
| idiots out of smart people.
| oasisaimlessly wrote:
| That's just like, your opinion, man.
| dataflow wrote:
| I read the page and don't understand what's going on. What is
| special about the 'wheel' group and what is su even "checking" in
| the first place? Isn't it just supposed to switch user? And what
| are the implications of not-checking whatever it was supposed to
| check? And I also don't get: if someone has the root password,
| can't they change what groups they're a member of?
| klodolph wrote:
| Basically, su vs sudo. Do you want any user to be able to
| become root, if they know the root password? Or do you want
| more control over the process?
| segfaultbuserr wrote:
| > _What is special about the 'wheel' group and what is su even
| "checking" in the first place?_
|
| By convention, "wheel" is a special Unix user group that
| determines who can use "su" and "sudo". Most "su" and "sudo"
| implementations allow the sysadmin to make their use exclusive
| to the trusted users inside the "wheel" group. In most systems,
| it's the default setting of "su", and optional for "sudo"
| (given as an example in /etc/sudoers).
|
| > _if someone has the root password, can 't they change what
| groups they're a member of?_
|
| No. If "su" is configured to be "wheel"-exclusive, you can't
| log in as root even if you have the password, because you
| cannot use "su" - unless you have direct access to the system
| console that allows you to type "username: root", which is
| almost never the case on servers that disable remote root
| login.
| [deleted]
| cperciva wrote:
| _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 to become root.
|
| _And I also don 't get: if someone has the root password,
| can't they change what groups they're a member of?_
|
| No, because they can't log in as root and (on non-broken
| systems) can't become root.
| ilyagr wrote:
| 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?
| tedunangst wrote:
| Wheel and su predate sudo by many years. sudo has a config
| file called sudoers; su has a config file called the wheel
| line in /etc/group.
| cdrt wrote:
| You're thinking about it backwards
|
| `su` predates `sudo` by a decade doesn't offer the fine-
| grained control `sudo` has. With `su` if you have the root
| password, you can do anything you want as root. With `sudo`
| admins can configure what commands users are allowed to run
| as root and could specifically block `sudo bash` from
| running.
| justsomehnguy wrote:
| 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-...
| ilyt wrote:
| That doesn't make any sense ? Why it should check some random
| group ?
| marcus0x62 wrote:
| The idea is to only allow user accounts in the wheel group to
| invoke su to take on root privileges. So, if someone had access
| to a random user account and knew the root password it wouldn't
| do them any good.
| jortr0n wrote:
| Here's an video of RMS talking about the period referenced in
| that man page regarding the introduction of passwords on user
| accounts:
|
| https://youtu.be/k0RYQVkQmWU?t=235
| e28eta wrote:
| I'm curious how Twenex worked, that a non-operator (root) account
| was able to patch the kernel. Maybe the kernel files were
| unprotected, because it'd be absurd for ordinary users to want to
| change them? Or did he have to use an exploit to elevate his
| privileges?
| pram wrote:
| Probably just didn't have filesystem permissions of any kind.
| rvnx wrote:
| There are little (to no?) situations where su has a good reason
| to check wheel.
|
| You either have the password, or you don't have it. But not
| something in-between.
|
| Outside of any ideology, in a scenario where you use su to become
| root, it's a very odd choice to link the wheel group to su;
| because if you know the password to the "root" user, and you have
| physical or remote access to the computer, you can likely just
| login as root.
|
| And if you can't, then it means you actually needed sudo su, not
| su.
|
| Those who actually need to be root, usually use sudo instead of
| su.
|
| In the other cases, if you just need to switch user, then no
| point at all to refer to wheel
| rcxdude wrote:
| sudo does completely obselete su, yes. (sudo su is redundant,
| you can just sudo -su)
| tux2bsd wrote:
| [dead]
| tedunangst wrote:
| What a bizarre anachronistic rant.
| klodolph wrote:
| 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.
| rvnx wrote:
| 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.
| rollcat wrote:
| 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.
| dathinab wrote:
| 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 handling to other programs like sudo or doas.
|
| Through tbh. the more I do learn the more I come to believe that
| uid/gid based permission handling is fundamentally flawed (but
| also good enough inside of a single application OCI(docker)
| image). The facts that Linux had to add a (very limited)
| capability system or that enterprise permission handling often
| goes through stuff like pollkit adding additional handling then
| just "gid/uid match" is I think very telling.
| dale_glass wrote:
| 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.
| jmclnx wrote:
| >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.
| rollcat wrote:
| GNU had to create a convention for the --long flags to fit
| all of their options.
|
| I think the convention itself is good - I prefer long flags
| in scripts for improved readability.
|
| But GNU is anything but minimal - compare GNU ls[1] with BSD
| ls[2], and try to recall the last time you needed
| --dereference-command-line-symlink-to-dir.
| [1]: https://linux.die.net/man/1/ls [2]:
| http://man.openbsd.org/ls
| marcus0x62 wrote:
| You're talking about tools and systems that just did not exist
| when the idea to have su check wheel membership came about.
|
| It was a different world, and having some basic speed bumps
| like not allowing random user accounts to su to root was useful
| at the time.
| vbezhenar wrote:
| 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).
| chasil wrote:
| 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?
| vbezhenar wrote:
| 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.
| bell-cot wrote:
| Reaction: Mr. Stallman's idyllic worldview does not seem to admit
| that someone may actually _own_ the computer system in question,
| or otherwise have legal rights to set limits on who uses the
| system, when, and for what purposes.
|
| And what was allowed by the social norms of the tiny 1980's *nix
| computing world, or what you can get away with when you're as
| famous as Mr. Stallman...those may not translate well to other
| contexts.
| nisegami wrote:
| Legal rights are not moral rights.
| nightpool wrote:
| Compare to https://news.ycombinator.com/item?id=37173339
| which has a lot of discussions of similar issues for "modern"
| security configurations. Just because IT admins _can_ choose
| to set a short session expiration on your SSO integration for
| your MDM managed laptop doesn 't mean that we should
| cooperate with them or develop tools to let them do that.
| indymike wrote:
| > someone may actually own the computer system in question,
|
| And that person may not be the systemadmin
| voz_ wrote:
| I can't stand his holier than thou writing. No amount of
| brilliance or clever code makes someone less of an asshole.
| rvnx wrote:
| Some people are so dazzled by singing and dancing skills,
| that they consider their singer to be a hero and a nice guy.
|
| Similarly, Stallman's coding expertise can sometimes
| overshadow any potential shortcomings in the non-IT subjects.
| treffer wrote:
| Well, I am a bit unsure if it does or does not translate
| well....
|
| One of my favorites is extensive rights management. Especially
| on CMS. More ofte than not it is part of a buying decision, but
| used Stallman style soon after.
|
| The observation that these credentials leak is correct. Or that
| you grow permissions over time for no other reason than doing
| work. A wheel group would today quickly attract users, too.
|
| So let it be. The latest iteration is "basically let everyone,
| but audited and short term only". I find that very close to
| Stallmanns idea, for very different reasons.
| hackan wrote:
| legal rights? "I'm on the side of the masses, not that of the
| rulers." He is pretty clear...
| bell-cot wrote:
| 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?
| NoZebra120vClip wrote:
| 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.
| segfaultbuserr wrote:
| 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...
| NoZebra120vClip wrote:
| 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!
| thriftwy wrote:
| Fork bomb does not need root to function.
| berbec wrote:
| :(){ :|:& };:
|
| explodes fine as a regular user
| TillE wrote:
| Only if you haven't configured sane limits.
| ye-olde-sysrq wrote:
| > If you are used to supporting the bosses and sysadmins in
| whatever they do, you might find this idea strange at first.
|
| Should this be _that_ far-fetched though? That employees might
| not be simple thralls of the capitalist, whose agency extends
| only as far as his master permits?
|
| 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.
|
| Their worldview was that where most people were "self-employed"
| - and if they weren't, employers were small and had a few or
| tens of employees at most. Or it was a matter of master and
| apprentices where both groups were investing heavily in each
| other in a trade and in the running of a shop.
|
| So, while yes our current system finds it a matter of course
| that employees are utterly subject to the whims of their
| employer and the legal and economic system fully supports them
| in this, does it have to be that way?
|
| (I know you can go be a contractor, but good luck with health
| insurance and etc etc etc all the other things that being yoked
| to an employer brings that I wish were just public taxpayer-
| funded services).
| aquova wrote:
| > 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, which owned something like
| 50% of the world's trade at the time and ruled several
| nations.
| ye-olde-sysrq wrote:
| 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.
| bell-cot wrote:
| > 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
| gorjusborg wrote:
| It does seem a very strange position when today's sensibilities
| are applied.
|
| I do understand the point of view when I think back. Today,
| Unix-like systems are everywhere. Learning it and working with
| it is a given. Back then, having access to a unix system was
| not a given. It was very expensive for hardware and software.
| The idea that one would be so close to the system and could be
| denied enough access by an overzealous BOFH was too much to
| take.
|
| It just goes to show that circumstances change, and things can
| get weird if we don't change with it.
| seabird wrote:
| Stallman's ideas are often informed by high trust environments
| and business arrangements where the cost of the software itself
| is a fraction of the TCO. There's a big disconnect between the
| environment where Stallman made up his mind (large
| education/business environments) and how most people are
| introduced to free software (low cost entry into technical
| computer usage).
|
| I used to think Stallman was an ideologue from a different era.
| When I started dealing with software projects measured in years
| and millions his thoughts made much more sense to me. When
| you're selling me a system that has a 6/7 digit implementation
| cost for it to stand any chance of meeting my goals,
| withholding the source code only serves to annoy me.
| dale_glass wrote:
| 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.
| e28eta wrote:
| 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
| twoodfin wrote:
| The etymological history of the group name is interesting:
|
| https://en.wikipedia.org/wiki/Wheel_(computing)
|
| _The term wheel was first applied to computer user privilege
| levels after the introduction of the TENEX operating system,
| later distributed under the name TOPS-20 in the 1960s and early
| 1970s. The term was derived from the slang phrase big wheel,
| referring to a person with great power or influence.
|
| In the 1980s, the term was imported into Unix culture due to the
| migration of operating system developers and users from
| TENEX/TOPS-20 to Unix._
___________________________________________________________________
(page generated 2023-08-18 23:01 UTC)