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

Run0, a systemd based alternative to sudo, announced

mastodon.social

Post reply on HN
Print view View original

871–880 of 902 posts

Re: Run0, a systemd based alternative to sudo, announced

#871

Post by panick21_ »

bayindirh wrote: post #870
panick21_ wrote: post #868

Earlier quoted context omitted.

Its not the best indicator but to claim its meaningless is idiotic. Specially since we are talking about free software, and not some software that Microsoft can preinstall on your laptop.

Just because it has been pushed by RedHat and others are semi-forced to adapt, it doesn't mean all distros got in line to get a copy of the software and get it adopted. Pulse has been replaced with the pipewire as soon as it arrived, for example.

Ah the old 'we were forced to use this free thing'. Sure.

> Pulse has been replaced with the pipewire as soon as it arrived

Pipewire combines alsa, pulse and jack. They all have different strength.

And Pulse was started by Lennard but he hasn't been involved for a very long time.

Re: Run0, a systemd based alternative to sudo, announced

#872

Post by airocker »

bayindirh wrote: post #785
whimsicalism wrote: post #779

Earlier quoted context omitted.

I thought most containers shared the same user, ie. `dockremap` in the case of docker. I understand academia has lots of different accounts.

Nope, full usermode containers (e.g.: apptainer) run under the user's own context, and furthermore under a cgroup (if we're talking HPC/SLURM at least) which restricts the user's resources to what they requested in their job file. Hence all containers are isolated from each other, not only at process level, but at user + cgroup level too. Apptainer: https://apptainer.org

I think a admin would better understand the system if there was only one subsystem doing a particular type of security and not two. Two subsystems doing security would lead to more problems down the road.

Re: Run0, a systemd based alternative to sudo, announced

#873

Post by airocker »

birdiesanders wrote: post #525
whimsicalism wrote: post #458

Earlier quoted context omitted.

is it? most HPC (if GPU clusters count) are probably in industry and managed by containers

Containers rely on many privilege separation systems to do what they do, they are in fact a rather extreme case of multi-user systems, but they tend to present as “single” user environs to the container’s processes.

Good software hides complexity. User does not have to understand user group permissions suid etc etc

Re: Run0, a systemd based alternative to sudo, announced

#874

Post by bayindirh »

panick21_ wrote: post #871
bayindirh wrote: post #870

Earlier quoted context omitted.

Just because it has been pushed by RedHat and others are semi-forced to adapt, it doesn't mean all distros got in line to get a copy of the software and get it adopted. Pulse has been replaced with the pipewire as soon as it arrived, for example.

Ah the old 'we were forced to use this free thing'. Sure. > Pulse has been replaced with the pipewire as soon as it arrived Pipewire combines alsa, pulse and jack. They all have different strength. And Pulse was started by Lennard but he hasn't been involved for a very long time.

> Ah the old 'we were forced to use this free thing'. Sure.

Well, I was a tech lead of a Debian derivative when Debian held the vote. I have seen and read enough. Didn't see the other "threats" thing, but since I had access to debian-devel, I was in the middle of it.

My views about systemd has not changed since then, and can be found if you search HN.

On the other hand, I have used 4-5 init systems in the last 20 years, and none of them were that aggressive and had the "we know the best" attitude, while going against all the best practices and making the same mistakes done in the past.

> Pipewire combines alsa, pulse and jack. They all have different strength.

Nope. ALSA is always there, working as the primary sink, delineating user space and hardware. I used Jack back in the day for recording, and never got to like pulse because of its backwards defaults and lassies-faire behavior about multi-channel audio (plus glitches, etc).

Pipewire is a great sound server which sits on top of ALSA, and replaces Pulse transparently, and makes everything 100x nicer along the way.

Lastly, it's Lennart Pottering. Not Lennard. :)

P.S.: It's important to understand that my views are not against the persons, but the behavior of the projects. I'd drink a nice round of beer with all of them, if I had the chance. :)

Re: Run0, a systemd based alternative to sudo, announced

#875

Post by sigil »

shiny22 wrote: post #865
sigil wrote: post #858

Earlier quoted context omitted.

I like s6! One of the key differences here is that s6-sudo builds on, rather than replaces, the standard unix permissions model. s6-sudod listens on a unix domain socket. Unix domain sockets are just files, so they have an owner, group and mode bits. The answer to "who is potentially allowed to run a differently-privileged command?" is just `ls -l /path/to.sock`. For finer-grained access control, a unix domain socket…

Like many other things in Unix, SO_PEERCRED and getpeereid are half-implemented hacks that should not be used for security. They both only return the uid that was used at the time of calling connect(). Meaning you have to be incredibly careful what you do when creating the socket and you cannot really pass any sockets off to other processes if you want to try to do security that way because they will still inherit th…

You do realize D-Bus also uses SO_PEERCRED right? And transitively polkit, systemd, and everything in that ecosystem.

https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/...

> Meaning you have to be incredibly careful what you do when creating the socket and you cannot really pass any sockets off to other processes if you want to try to do security that way because they will still inherit the wrong credentials.

I see nothing new here beyond "handle privileged resources with care." Don't overshare. Got an open pipe to `sh` running as root? Maybe you oughtta set O_CLOEXEC on that fd before you exec and overshare with a child. Got a socket that's been peer authed? The same.

This is pretty basic unix stuff. If you stick to the basics and avoid the siren call of complexity, the security properties remain relatively easy to reason about. Most privileged resources are fds. Mind your fds.

I'm not a huge fan of sending file descriptors over sockets – maybe we agree on that part.

Re: Run0, a systemd based alternative to sudo, announced

#876

Post by panick21_ »

bayindirh wrote: post #874
panick21_ wrote: post #871

Earlier quoted context omitted.

Ah the old 'we were forced to use this free thing'. Sure. > Pulse has been replaced with the pipewire as soon as it arrived Pipewire combines alsa, pulse and jack. They all have different strength. And Pulse was started by Lennard but he hasn't been involved for a very long time.

> Ah the old 'we were forced to use this free thing'. Sure. Well, I was a tech lead of a Debian derivative when Debian held the vote. I have seen and read enough. Didn't see the other "threats" thing, but since I had access to debian-devel, I was in the middle of it. My views about systemd has not changed since then, and can be found if you search HN. On the other hand, I have used 4-5 init systems in the last 20 yea…

The reality Debian didnt want to or couldnt develop their own. The system people used them was simply shit. And the alternatives like Upstart were just crap.

Nobody forced Debian. I followed it live too. I remember him talking to Debian and he made a technical argument for it.

I had already switched to Arch and had already been using Systemd for years at that point.

The reality is, nobody was stepping up with better solutions. Would porting SMF have been better, maybe, but nobody was porting that.

There are distros with Systemd, often very compatible ones, and almost nobody uses them.

BSD folks for years have been hoping for the linux exodus over systemd and it has never happen.

And it has to be said a 1000x times. Systemd was never just init and it mever claimed it was. By now Systemd is just a software project that makes all kind of software that you can use with or without systemd the service manager.

The should just call it the "Linux Userland Software Group" and change their naming. Then people wouldnt get triggered by the term 'systemd'.

You can have whatever technical opinion you like about systemd. Fact is most people use it, including in very large organisations. And the other fact is nobody forced systemd on Debian. Whatever consipiricy was apread in 'Devel' (and elsewhere).

Re: Run0, a systemd based alternative to sudo, announced

#877

Post by bayindirh »

panick21_ wrote: post #876
bayindirh wrote: post #874

Earlier quoted context omitted.

> Ah the old 'we were forced to use this free thing'. Sure. Well, I was a tech lead of a Debian derivative when Debian held the vote. I have seen and read enough. Didn't see the other "threats" thing, but since I had access to debian-devel, I was in the middle of it. My views about systemd has not changed since then, and can be found if you search HN. On the other hand, I have used 4-5 init systems in the last 20 yea…

The reality Debian didnt want to or couldnt develop their own. The system people used them was simply shit. And the alternatives like Upstart were just crap. Nobody forced Debian. I followed it live too. I remember him talking to Debian and he made a technical argument for it. I had already switched to Arch and had already been using Systemd for years at that point. The reality is, nobody was stepping up with better…

Thanks for confirming that I can have technical opinions about systemd, as an admin who touches more than a thousand physical servers. :)

I'll agree to disagree on the systemd's "we will replace anything and everything we even slightly dislike, and slowly make them dependent on systemd (the service manager) while not listening to you and your pesky experiences" attitude, and wish you more power for your future endeavors.

Have a nice day. :)

Re: Run0, a systemd based alternative to sudo, announced

#878

Post by 9dev »

michaelcampbell wrote: post #846
9dev wrote: post #781

Earlier quoted context omitted.

I honestly have no clue what you mean. You can take unit files, journald, timers, and all the other neat features from my cold, dead hands. I’m not going back to writing brittle shell scripts; systemd has made my life SO much easier.

> I’m not going back to writing brittle shell scripts Then stop doing that.

Ah, Right. So, how would I add support for reloading the configuration of my init-Script service without restarting it, in a way that works across all major distributions and versions, without googling?

Show me your script, compare it to the one line of my unit file, and tell me that isn’t brittle.

Re: Run0, a systemd based alternative to sudo, announced

#879

Post by kasabali »

flexagoon wrote: post #724
metalspoon wrote: post #494

Earlier quoted context omitted.

Yes. I prefer having tools that do one thing well. That's the point of unix. How the user uses them should be up to her. GNOME offering a monolithic environment with heavy opinionation is the opposite.

How is GNOME a "monolithic environment"? The entire GNOME ecosystem is basically small apps that do a single thing well: https://apps.gnome.org/

So is X11, by that logic

https://cyber.dabamos.de/unix/x11/

Re: Run0, a systemd based alternative to sudo, announced

#880

Post by throwaway7356 »

sigil wrote: post #858
mananaysiempre wrote: post #790

Earlier quoted context omitted.

To be fair, this is not at all Poettering’s idea. There is, for example, precedent in the form of s6-sudo[1], a utility from the s6 service supervisor, itself very much an anti-systemd project (except I believe it predates systemd?..). And honestly I’d be okay with a suidless Unix. For example, as best as I can tell, the only reason the kernel needs to know what executable formats even are—beyond the bare minimum nee…

I like s6! One of the key differences here is that s6-sudo builds on, rather than replaces, the standard unix permissions model. s6-sudod listens on a unix domain socket. Unix domain sockets are just files, so they have an owner, group and mode bits. The answer to "who is potentially allowed to run a differently-privileged command?" is just `ls -l /path/to.sock`. For finer-grained access control, a unix domain socket…

> Unix domain sockets are just files, so they have an owner, group and mode bits. The answer to "who is potentially allowed to run a differently-privileged command?" is just `ls -l /path/to.sock`.

Yeah, except that is not true. To quote unix(7):

       On Linux, connecting to a stream socket object requires write permission on that socket; sending
       a datagram to a datagram socket likewise requires write permission on that socket.   POSIX  does
       not make any statement about the effect of the permissions on a socket file, and on some systems
       (e.g.,  older  BSDs),  the socket permissions are ignored.  Portable programs should not rely on
       this feature for security.
So s6 just has a wide, easily exploitable security hole there. Or is not portable, contrary to its claims.
Post reply on HN