Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ftp.gnu.org

Post reply on HN
Print view View original

111–120 of 150 posts

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

#111

Post by wruza »

gorgoiler wrote: post #109
fiddlerwoaroof wrote: post #92

Earlier quoted context omitted.

You can do this on basically any modern unix by passing file descriptors over a unix socket: the “graphical editor” server would launch as a user that can’t access anything except a socket and then users would open files by pushing an open fd to the editor over its socket.

This sounds interesting but I don’t understand what the underlying mechanism is. For me, a file descriptor is just an int corresponding to something I can read from and write to and a socket just carries bytes. I don’t understand how an FD can be sent over a socket or, if it can, how that’s anything more than just sending an int?

https://en.wikipedia.org/wiki/Unix_domain_socket

In addition to sending data, processes may send file descriptors across a Unix domain socket connection using the sendmsg() and recvmsg() system calls. This allows the sending processes to grant the receiving process access to a file descriptor for which the receiving process otherwise does not have access.[2][3] This can be used to implement a rudimentary form of capability-based security.

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

#113

Post by chasil »

vbezhenar wrote: post #66
chasil wrote: post #64

Earlier quoted context omitted.

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 ded…

On this, you must understand the original "poverty of UNIX," in that it originated on a 16-bit PDP-11.

There was no room in that environment for a running service to elevate privilege, so it was implemented as a kernel system call.

This poverty meant that efficiency was required, and setuid was the most efficient mechanism.

It was a reasonable and efficient mechanism for its time, and it has successfully scaled to the realm of modern supercomputers, and remains efficient on the lowliest of embedded systems.

Maybe there was a more secure option bearing in mind of all the places that UNIX was forced to go, but I cannot think of one.

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

#114

Post by fiddlerwoaroof »

gorgoiler wrote: post #109
fiddlerwoaroof wrote: post #92

Earlier quoted context omitted.

You can do this on basically any modern unix by passing file descriptors over a unix socket: the “graphical editor” server would launch as a user that can’t access anything except a socket and then users would open files by pushing an open fd to the editor over its socket.

This sounds interesting but I don’t understand what the underlying mechanism is. For me, a file descriptor is just an int corresponding to something I can read from and write to and a socket just carries bytes. I don’t understand how an FD can be sent over a socket or, if it can, how that’s anything more than just sending an int?

I’m not exactly sure of the terminology, but there’s an opaque object corresponding to the int that can be passed between processes via unix sockets. I believe nginx and other web servers do this to transfer open connections to the new server process on restart without interruption.

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

#115

Post by azlev »

gorgoiler wrote: post #109
fiddlerwoaroof wrote: post #92

Earlier quoted context omitted.

You can do this on basically any modern unix by passing file descriptors over a unix socket: the “graphical editor” server would launch as a user that can’t access anything except a socket and then users would open files by pushing an open fd to the editor over its socket.

This sounds interesting but I don’t understand what the underlying mechanism is. For me, a file descriptor is just an int corresponding to something I can read from and write to and a socket just carries bytes. I don’t understand how an FD can be sent over a socket or, if it can, how that’s anything more than just sending an int?

Ancillary data: https://linux.die.net/man/3/cmsg

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

#116

Post by ilyt »

gorgoiler wrote: post #109
fiddlerwoaroof wrote: post #92

Earlier quoted context omitted.

You can do this on basically any modern unix by passing file descriptors over a unix socket: the “graphical editor” server would launch as a user that can’t access anything except a socket and then users would open files by pushing an open fd to the editor over its socket.

This sounds interesting but I don’t understand what the underlying mechanism is. For me, a file descriptor is just an int corresponding to something I can read from and write to and a socket just carries bytes. I don’t understand how an FD can be sent over a socket or, if it can, how that’s anything more than just sending an int?

It's special API that tells kernel to duplicate FD and give it to different process.

https://linux.die.net/man/7/unix

    SCM_RIGHTS
        Send or receive a set of open file descriptors from another process. The data
        portion  contains an integer array of the file descriptors. The passed file 
        descriptors behave as though they have been created with dup(2).
There are few interesting uses like for example, if you want to restart a network server, the old process can send its open, listening socket to the new process and thus achieve seamless switchover.

Other nifty thing with UNIX sockets is that you can just... read which user sent the message and as it is kernel adding that metadata you're 100% sure it came from that user. That's for example how you can set postgresql so say a certain user in the system can log as themselves without having to have a password.

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

#117

Post by thayne »

Someone wrote: post #87
ilyt wrote: post #79

Earlier quoted context omitted.

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…

> 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 on…

That limits your application though. It means you have to use the system file picker. For many apps that might be fine. But it means you can't have something like vim or emacs where you open files with a command. Or have an option that does something like open a sibling .h file when you are editing a .c file. Or search up the directory to find the applicable .editorconfig file.

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

#118

Post by mcpackieh »

rvnx wrote: post #23
voz_ wrote: post #4

Earlier quoted context omitted.

I can’t stand his holier than thou writing. No amount of brilliance or clever code makes someone less of an asshole.

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.

Personally, I'm dazzled by Stallman's singing and dancing skills.

Join us now and share the software,

You'lll be free, hackers, you'll be freee

Also by his uncanny tendency to be proven correct in matters concerning software freedom. His coding expertise are tertiary at most. Honestly, I never see people praise RMS's coding expertise, where are you even getting that idea from? I don't think you get it why people like RMS.

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

#119

Post by 1letterunixname »

nine_k wrote: post #3

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

I remember having BootCommander on a test box containing Windows 95 (and a bunch of other crap) to boot to up to 16 OSes.

Back in the day, university campus networks popularized a "cluster" approach of logging in to specific machines whereby hosts followed the pattern: $(uname)[0-9]{2}. You would soon setup authorized_keys and a script that would check the load of all machines by iterating ssh. The same home directory would be shared to all machines, regardless of OS, so portability of shells scripts and POSIX/C code was necessary.

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

#120

Post by 1letterunixname »

jml7c5 wrote: post #16
nine_k wrote: post #3

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

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/

The use-case is concerned with is multi-user, most likely remote login, sometimes desktop login. He whines about everyone not having root and breaking the box. Too bad. If you don't like the isolation and privilege separation a system provides, use virtualization, containers, run your own, or change the OS to allow your specialness that doesn't affect other users.

It's not wheel's fault, and so substituting root group for wheel was nothing more than a special snowflake move by someone who thought the sysadmins were holding back and the "enemy".

Post reply on HN