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

891–900 of 902 posts

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

#891

Post by snvzz »

throwaway7356 wrote: post #883
snvzz wrote: post #681

Earlier quoted context omitted.

XMODEM and the like expect the terminal stream to not have garbage added by e.g. run0. The terminal line should be clean between XMODEM at the terminal emulator and at the client end.

Is xmodem still used outside of computer museums (including private computer museums)?

It's e.g. still very popular with embedded development. One example: u-boot supports it.

It is the easiest way to upload an image to u-boot, as it does use the same terminal, thus there is no need to set up a secondary path; If you can talk with the u-boot CLI, you can also upload with xmodem.

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

#892

Post by _flux »

immibis wrote: post #890
_flux wrote: post #648

Earlier quoted context omitted.

I imagine these questions are what might make this project non-trivial, but surely achievable. > If I chroot and then run0 will that process also run in the chroot? That's an interesting question and it's not quite clear to me what should be the answer. For example, one legit answer might be that it would not work at all (in which case you would need to use some other tool that fits your needs), or another would be t…

I expect that when I run "sudo rm /foo" it should try to affect the same file as "rm /foo". Especially when I just checked, without sudo, that /foo was the correct file.

If there is a non-error effect in running sudo rm /foo, then indeed it should have the same effect as rm /foo as root in the chroot environment.

But using sudo, or even root, in a chroot environment isn't good security practice in the first place. For example, the environment's /etc/sudoers, /etc/shadow, /etc/passwd can all be different (but actual user ids are shared), while the environment could mknod the root filesystem device, mount parts of the host under /usr and /home and quite possibly elevate its access to the host filesystem, in which case sudo in a chroot environment would interact with the host in perhaps ways that are not directly constrainable in sudoers in the first place.

I imagine it's possible to carefully construct the chroot environment and craft /etc/sudoers in a way to avoid this, but I wouldn't even try.

In a better contained system implemented with namespaces (as in docker) sudo should work as expected. I imagine e.g. with docker you could have a service that responds to the system dbus messages, either as a separate daemon in the container or something even provided by docker itself. Or, maybe the requests from the container could be forwarded to the main systemd, with information about the context the request comes from, and let it choose how to move forward.

In the end I don't think I agree that a sudo replacement exchanging messages directly with the systemd is the best way to go. There could be another daemon, run by systemd (or not), that handles these messages. I suppose in the case of dbus there is no "dbus firewall" to limit the access to dbus as one can limit access to Unix domain sockets with plain old permissions, though, so perhaps the security benefits would be minimal in the dbus architecture.

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

#893

Post by chillfox »

klysm wrote: post #869
michaelcampbell wrote: post #846

Earlier quoted context omitted.

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

Writing robust shell scripts ranges from hard to incredibly difficult. The number of footguns is insane

It’s really not that hard. I have found that writing robust shell scripts is pretty easy.

Don’t use bash, stick to #!/bin/sh, use shellcheck, wrap all variables in quotes, use command -v to check if a binary is available before trying to use it, and don’t use gnu specific things.

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

#894

Post by klysm »

chillfox wrote: post #893
klysm wrote: post #869

Earlier quoted context omitted.

Writing robust shell scripts ranges from hard to incredibly difficult. The number of footguns is insane

It’s really not that hard. I have found that writing robust shell scripts is pretty easy. Don’t use bash, stick to #!/bin/sh, use shellcheck, wrap all variables in quotes, use command -v to check if a binary is available before trying to use it, and don’t use gnu specific things.

Sure all of that is easy, but control flow is a nightmare. How do you deal with cleaning up resources on failures? Idempotency? Traps? It’s a fucking mess

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

#895

Post by SkyMarshal »

cesaref wrote: post #639
SkyMarshal wrote: post #434

Earlier quoted context omitted.

alias sudo="run0" If run0 supports the same flags and parameters they'll be interchangeable with just an alias.

I thought this was a security fix? Let's say I find a problem in ssh, I don't update it, call it 'newssh' and tell people to use an alias to point ssh to newssh do i? I just fix the app.

It's a non-trivial security fix with an entirely new architecture.

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

#896

Post by chillfox »

klysm wrote: post #894
chillfox wrote: post #893

Earlier quoted context omitted.

It’s really not that hard. I have found that writing robust shell scripts is pretty easy. Don’t use bash, stick to #!/bin/sh, use shellcheck, wrap all variables in quotes, use command -v to check if a binary is available before trying to use it, and don’t use gnu specific things.

Sure all of that is easy, but control flow is a nightmare. How do you deal with cleaning up resources on failures? Idempotency? Traps? It’s a fucking mess

I don't know what to tell you other than skill issue.

I don't think shell is a great language or even that good for configuration, but it is pretty simple and the quantity of footguns are similar to JavaScript.

My issue with systemd is not the configuration file/language, that bit is pretty cool. My issue is mostly with all of the half-assed auxiliary services they keep pushing and something is not quite right with systemd itself, the complexity causes issues with weird edge cases.

Early in my career I was all for systemd, thought it was the greatest thing ever, then I got bit by the edge cases a few too many times. Meanwhile I have had zero issues with openrc or s6.

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

#897

Post by mbreese »

airocker wrote: post #872
bayindirh wrote: post #785

Earlier quoted context omitted.

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.

For HPC, there are two different contexts where users need to be considered - interactive use and batch job processing. Users login to a cluster, write their scripts, work with files, etc. This is your typical user account stuff. But they also submit jobs here.

Second, there are the jobs users submit. These are often executed on separate nodes and the usage is managed. Here you have both user and cgroup limits in place. The cgroups make sure that the jobs on have the required resources. The user authentication makes sure that the job can read/write data as the user. This was the user can work with their data on the interactive nodes.

So the two different systems have different rationales, and both are needed. It all depends on the context.

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

#898

Post by airocker »

mbreese wrote: post #897
airocker wrote: post #872

Earlier quoted context omitted.

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.

For HPC, there are two different contexts where users need to be considered - interactive use and batch job processing. Users login to a cluster, write their scripts, work with files, etc. This is your typical user account stuff. But they also submit jobs here. Second, there are the jobs users submit. These are often executed on separate nodes and the usage is managed. Here you have both user and cgroup limits in pla…

If we forget how the current system is architected, we are looking at two problems: First problem is that Linux capabilities are also dealing with isolating processes so they have limited capabilities because the user based isolation is not enough. Second problem is that local identity has no relation to the cloud identity which is undesirable. If we remove user based authentication and rely on capabilities only with identity served by cloud or kubernetes, it could be a simpler way to do authenticating and authorization

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

#899

Post by mbreese »

airocker wrote: post #898
mbreese wrote: post #897

Earlier quoted context omitted.

For HPC, there are two different contexts where users need to be considered - interactive use and batch job processing. Users login to a cluster, write their scripts, work with files, etc. This is your typical user account stuff. But they also submit jobs here. Second, there are the jobs users submit. These are often executed on separate nodes and the usage is managed. Here you have both user and cgroup limits in pla…

If we forget how the current system is architected, we are looking at two problems: First problem is that Linux capabilities are also dealing with isolating processes so they have limited capabilities because the user based isolation is not enough. Second problem is that local identity has no relation to the cloud identity which is undesirable. If we remove user based authentication and rely on capabilities only with…

I'm not sure I even follow...

The primary point of user-authentication is that we need to be able to read/write data and programs. So you have to have a user-level authentication mechanism someplace to be able to read and write data. cgroups are used primarily for restricting resources, so those two sets of restrictions are largely orthogonal to each other.

Second, user-authentication is almost always backed (at least on interactive nodes) by an LDAP or some other networked mechanism, so I'm not sure what "cloud" or "k8s" really adds here.

If you're trying to say that we should just run HPC jobs in the cloud, that's an option. It's not necessarily a great option from a long-term budget perspective, but it's an option.

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

#900

Post by ximm »

panick21_ wrote: post #868
lucideer wrote: post #867

Earlier quoted context omitted.

> nobody uses his software Yes, you're absolutely right. Popularity is the best indicator of quality.

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 a short reminder that Lennart is working for Microsoft. https://unpkg.com/@material-design-icons/svg@0.14.13/outline...
Post reply on HN