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

391–400 of 902 posts

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

#391

Post by noinsight »

pmontra wrote: post #296
Arnavion wrote: post #261

Earlier quoted context omitted.

Technically `sudo -u` can switch to any user on the system while only a limited few would be allowed as ssh targets. Even root might not be allowed as an ssh target if `PermitRootLogin` is set to `no`, which I do on all my systems.

I do use that a lot sudo -H -u user bash after I ssh into a server with my own account. That other user might even be a no login account.

You can just use `-i` instead of `bash`. (This method indeed requires a shell configured, your method is needed with nologin.)

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

#392

Post by acdha »

cduzz wrote: post #369
lolinder wrote: post #249

Earlier quoted context omitted.

> I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there. > I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename. My memory of thi…

I appreciate that someone's invented shoes you inflate and snap. I can see some advantages. That said, when I'm in a hurry and going to do a thing that I've been doing every day of my life, I'm really not a big fan of having to stop what I'm doing and reexamine a tool I've used all my life to figure out how to use it. I learned this stuff decades ago and I'm not anxious to relearn how to do it for a fractional improv…

Don’t think of it as relearning a tool, think of it as learning one tool which works for everything. You no longer have to implement your own log rotation, compression, etc. or work out which configuration each program needs to do that in the manner you expect – for example, “is it safe to rotate a log file?” requires you to know implementation details on each program.

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

#393

Post by ranger_danger »

CuriousCosmic wrote: post #295
ranger_danger wrote: post #159

Earlier quoted context omitted.

> it requires a ton of systemd infra to use I understand your frustration, but is it really fair to criticize a systemd feature for requiring systemd itself?

When that feature is trying to replace an existing, portable feature? Yes.

Isn't that most of systemd's extra stuff already? like DHCP, network manager, time daemon, boot loader etc.

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

#394

Post by zamadatix »

dsr_ wrote: post #337
zamadatix wrote: post #305

Earlier quoted context omitted.

I think it's more that the default seems backwards than the lack of ability to change it.

It's three things: * here is a feature which we are defaulting to on * there's no persistent config for it * we know better than you do about your preferences

"Defaulting to on" is just a symlink to an existing binary so that's not really much a problem.

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

#395

Post by riddley »

esoterae wrote: post #214
kbar13 wrote: post #45

systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run…

No, it hasn't. You forget, the reason systemd was originally rationalized for its insertion into our trees was "boot times are too slow". Its chameleon-like nature and ability to solve the hastily described problem du jour seems to be its only consistently touted feature. Bash scripts that start processes are ephemeral. If it's signal handling you want, that was your program's problem. Either that or your program did…

Same thing is happening with Wayland. It reduces features adds complexity and solves no new problems but here it comes.

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

#396

Post by rezonant »

citrin_ru wrote: post #380
lolinder wrote: post #249

Earlier quoted context omitted.

> I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there. > I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename. My memory of thi…

'journalctl -u service -f' takes many seconds to start showing logs (even with 4GB journal size limit which not that much). 'tail -f /var/log/service' works without a noticeable delay (be it 1kb or 100Gb log file). For me it's a huge regression.

While I'm very pro journalctl, this is very true. They should put some work into the initial read performance on big journals.

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

#397

Post by rcxdude »

agwa wrote: post #301
abridgett wrote: post #178

I'm not sure it can replace non-trivial setups - sudo/doas looks set to stay. e.g when you need to restrict a set of users to run only certain applications with certain other users. sudo can do this (even if the config format can be painful).

Good news! run0 will use polkit[1], which uses JavaScript for its rules[2], so there's no limit to how complex your rules can get! On the other hand, maybe adding a JavaScript interpreter to Linux's trusted computing base isn't good news... [1] https://mastodon.social/@pid_eins/112353420303876549 [2] https://www.freedesktop.org/software/polkit/docs/latest/polk...

It's a heck if a lot better than a random smattering of shared libraries getting pulled into a random high-priviledge context which also inherits some other context from whoever is asking for authentication. Polkit gets a lot of flack but PAM is absolutely mad.

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

#398

Post by rezonant »

sunshowers wrote: post #338
agilob wrote: post #230

Earlier quoted context omitted.

> remember when you had to write bash scripts to start, stop, restart services This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar cr…

I've recently become a fan of the `-x` flag to journalctl, which adds additional context to log entries and even suggests remediations at times. I've identified and fixed several issues on my Linux systems that way. Kind of hard to get that with tail -f!

Ooh nice. What are some examples of things it will catch?

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

#399

Post by riddley »

yjftsjthsd-h wrote: post #237
SR2Z wrote: post #218

Earlier quoted context omitted.

Why wouldn't SSH be linked to XZ? Isn't it supported as a compression method for connections?

IIRC, xz was used by a systemd library, and that systemd library got added to sshd so it could tell systemd when it had started or something like that. SSH itself doesn't use xz.

xz is a compression library.

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

#400

Post by lmm »

Xylakant wrote: post #43
lmm wrote: post #32

Earlier quoted context omitted.

> - Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library. Why was that? Would that "trivial" approach have broken the next time systemd made one of their incompatible interface changes, perhaps? Was using libsystemd the kind of thing the systemd maintainers recommended? > And therefore, systemd is insecure? Systems with systemd had a vulne…

You're not making a very good point here. A lot of packages have a transitive dependency on liblzma - for example everything that depends on libxml since that depends on liblzma https://packages.debian.org/sid/libxml2 . LZMA is a pretty widely used compression algorithm, I'm absolutely certain there's other juicy targets that depend on liblzma. The reason why "only" sshd on debian/ubuntu was affected is that the atta…

> A lot of packages have a transitive dependency on liblzma - for example everything that depends on libxml since that depends on liblzma https://packages.debian.org/sid/libxml2.

Sure. But security-critical software like SSH would certainly think twice before bringing in such a huge and complex dependency as an XML parser.

> I'm absolutely certain there's other juicy targets that depend on liblzma.

You could probably make a system package manager (which has obvious reasons to depend on a compression algorithm) do something nefarious. But that would be a more complex chain of exploitation with more chance for things to go wrong. Most security teams put more attention on security-critical parts like SSH, and I think most people would agree they're right to do so.

Post reply on HN