[HN Gopher] Run0, a systemd based alternative to sudo, announced
___________________________________________________________________
Run0, a systemd based alternative to sudo, announced
Author : CoolCold
Score : 164 points
Date : 2024-04-29 23:59 UTC (23 hours ago)
(HTM) web link (mastodon.social)
(TXT) w3m dump (mastodon.social)
| CoolCold wrote:
| Uses polkit.
|
| run0, which behaves like sudo, but works entirely differently and
| is not SUID. Run0 asks the services manager to create a shell or
| command under the target user's ID, creating a new PTY, sending
| data back and forth from the originating TTY and the new PTY.
| segasaturn wrote:
| How hard would it be to create a program to send a signal to
| polkit "impersonating" run0 and obtains a root shell? :)
| gh02t wrote:
| Is that even a problem? Any program can shell out to sudo,
| hence why you shouldn't set NOPASSWD in sudoers. Polkit takes
| in a request on an unprivileged interface, that request is
| evaluated in privileged code against the set of privilege
| rules, and then passed the proper capabilities if the rules
| allow. This includes a mechanism where it can, if desired,
| prompt a user to enter a password etc to prevent a rogue
| program silently acquiring root. But even in the worst case,
| the rogue program is not going to acquire any capabilities
| that you would not otherwise have as with sudo, and the
| breakpoint between privileged and unprivileged code is (in
| theory) more tightly defined and controlled.
| TacticalCoder wrote:
| > Or in other words: the target command is invoked in an isolated
| exec context, freshly forked off PID 1, ...
|
| Of course. The solution to every Linux "problem" is, of fucking
| course, to have the PID1 spread is tentacles to yet more part of
| Linux.
|
| Every single problem can be solved by giving yet more power to
| PID1... Except the problem of PID1 having too much power.
| wkat4242 wrote:
| I'm really starting to hate the sub-community in Linux that tries
| to constantly change it.
|
| I don't want to learn a new network config alternative with every
| update (Ubuntu changed its net config tool again with 24.04). I
| don't want an immutable os. I don't want to learn to write new
| config files. I just want to do what I've been doing but with new
| packages. If there's a problem with something, just fix it. Don't
| throw out the whole thing.
|
| I moved to FreeBSD and am happy for its reluctance to change. If
| there is any, it's usually offering something genuinely new to me
| as a feature and to boot I only need to learn about it if I need
| it.
|
| Hardware support is much lower but it's worth it IMO. I had the
| same irritation with macOS. Every release breaking something
| essential that was part of my workflow and i didn't want to
| change. Eventually I did change but away from Apple.
|
| I don't want to change to LennartOS either.
| hasselhoftd wrote:
| Agreed. I've taken to treating my linux installs like I used to
| treat Windows: no internet access expect application specific.
|
| For example, I run a Visionfive 2 OpenBSD install with squid,
| everything else has to go through that.
| cyberpunk wrote:
| Curious why squid and not pf?
| CoolCold wrote:
| To help myself to understand others better, I made some efforts
| to look and keep looking outside my bubble.
|
| That's not simple though- humans tend to think THEY know better
| for all others while it's often not.
|
| Say you don't want to have immutable distros, but many want.
| Android or Talos or even OS for network switches are nice
| examples.
|
| Linux based solutions and products related community is wide
| and to keep up with evolution one needs to adapt and adopt
| changes.
|
| We already see what happens for immutable/stale systems like
| FreeBSD - even TrueNAS is abandoning it, dying as predicted by
| experts since 2008-2010.
|
| On other side - nothing stops you from keep using sudo or even
| choose disto vendor which doesn't use systemd, there is a
| choice, not thing set in stone.
|
| Say I don't plan to switch to run0 in any near future - first
| it's not gonna be in any LTS disto, 2nd - it seems to be
| lacking LDAP based rules and very much likely other important
| features.
| dig1 wrote:
| This is the main reason why I'm still on Slackware. Pat is
| keeping the same thing for the last 20-30 years. Sure, he had
| to introduce some stuff, like NetworkManager or PulseAudio, to
| keep up with the latest software versions, but every major
| change is postponed as much as possible. Hell, even systemd is
| not there yet, and I'm pleased about that.
| metalforever wrote:
| Same, I am also hiding on Slackware .
| trallnag wrote:
| So Slackware is your main OS? Or is it just something to
| play around with?
| pmlnr wrote:
| > I moved to FreeBSD and am happy for its reluctance to change.
|
| Same here on server. Desktop is still linux.
| andrewstuart wrote:
| I want the change.
|
| I love it when new and better ways are found to do things.
|
| I love it that Linux is constantly improving and moving
| forward.
|
| I'm willing to accept along the way some things seem to be mis
| steps (I'm looking at you snap packaging).
|
| I love it that improved network configuration systems are being
| adopted because network configuration is a pain.
|
| I love systemd and when new stuf comes out from the systemd
| project I think "gee I'm glad finally someone is taking a
| wholistic look at and fixing that messy inconsistent evolved
| corner of Linux and replacing it with well thought out powerful
| and integrated solution."
|
| Bring on the change, change is the best thing about computing
| and software. I own vintage computers but wouldn't want to live
| there.
| cyberpunk wrote:
| I've been running Ubuntu boxes in prod since 12.x -- there is
| no "improved" way to put an ip address on an interface
| besides writing something to a file in /etc, but every update
| this file changes, or it's format does.
|
| It's bullshit and I wish it would end.
|
| Alas, keeps the consultant bucks flooding in when we have to
| rewrite a load of cfgmgt to go to 24.04 I guess..
| iforgotpassword wrote:
| I just switch every system to systemd-networkd immediately.
| The same .ini sytax as for service files, and dependencies
| are easy to handle, e.g. on one system I have two physical
| Interfaces eth0 and eth1, I want two vlans on eth0, and
| then bridge one of those vlans with eth1 and then run a
| DHCP client on that bridge but at the same time assign an
| additional IP address. This is dead simple to describe with
| one .ini file per vlan/bridge. Seriously the first time I
| feel like I'm not fighting an archaic config syntax, fixing
| up crap in some post-hook.d script, or give up entirely on
| any config language and just have a convoluted script
| setting up everything manually.
|
| It's also easy to explicitly express "weird" stuff like
| "run DHCP client and use all the config options except the
| default route". Seriously a couple times I needed to do
| dumb shit and was like "there's no way they let you do
| this" but no, there's a way to do it.
|
| And I'm pretty positive the config files will stay stable
| over the coming years and any new networking features will
| get appropriate config options in newer versions.
| cyberpunk wrote:
| Eh, I could. But I'm quite sure that the method of
| switching to systemd-networkd also requires the same if
| not much more maintenance as simply changing the ifconfig
| template every few years...
|
| I really don't care about interface configurations that
| much. It's an annoyance, but one that's quite easy to
| fix. I think introducing yet another network
| configuration here isn't the answer, but my linux fleet
| just run k8s anyway and network config on the linux level
| is quite simple before we get into cillium/istio/etc :}
| iforgotpassword wrote:
| Sure, I made that choice at a time where after upgrading,
| Ubuntu suddenly wanted netplan, debian stayed with
| /etc/network/interfaces and I think fedora went with
| networkmanager. So I though f- it, they all have systemd
| so I'll give networkd a spin. And never looked back.
|
| So maybe don't just switch out of the blue right now if
| you've got a working setup, but maybe keep it in mind for
| the next time. :)
| JohnFen wrote:
| > I love it when new and better ways are found to do things.
|
| I do, too. But I also really hate it when those new and
| better ways make things worse for me. Systemd does that in a
| couple of important ways. There is even some network-related
| startup stuff that I can no longer make work automatically at
| all. For me personally, systemd is a regression, not an
| advance.
|
| But I also recognize that the Linux world is not duty-bound
| to make sure it remains excellent for me, and I've pretty
| much given up on advocating for my needs in the Linux space.
| There's no point, particularly with the systemd crowd.
| paulddraper wrote:
| It's very fair to eschew change for negligible improvements.
|
| But I've also seen the community defend terrible stuff just
| because.
|
| Look at what happened with the init system. System V, fstab,
| etc was awful. Doing anything with a reasonable level of
| robustness was grotesquely obtuse and complicated. And yet it
| was "perfectly fine" to the greybeards. Alternative proposals
| were near zero.
|
| I don't have a dog in the networkmanager/netplan fight. It
| could be that one is irrelevant; given history, I have a hard
| time trusting what I hear.
|
| sudo has quirks for sure (which is why you see a number of
| alternatives).
| chuckadams wrote:
| Daemontools was pretty popular with greybeards, actually. But
| yeah, daemontools/runit/s6 and company have always been for
| handcrafted server setups, where the thing about init scripts
| and unit files is that they're a standard thing a package can
| supply and have work out of the box with minimal tweaking
| across distros.
|
| Any serious challenge to systemd nowadays is probably going
| to have to at least offer compatibility with it. No one is
| going to rip it all out and start over again (again).
| exe34 wrote:
| I so want to ditch Linux for bsd, but hardware support, both
| for my current laptop and future pain in searching for
| compatible hardware is the only thing putting me off. And my
| server needs cuda for my AI shenanigans, so probably no bsd
| there either ...
| INTPenis wrote:
| That's funny. It's like there are two camps, conservatives, and
| progressives. ;)
|
| Jokes aside, I just think that life is constant change and the
| programming industry is a good example of that. Coding
| practices have improved a lot in the last few years and will
| continue to improve with new knowledge and new technology.
| Sometimes it's better to start anew from scratch than trying to
| adapt old code into new practices.
|
| Btw this is not a young whippersnapper saying this. My first IT
| job was on FreeBSD and OpenBSD. I was a full-time FreeBSD user
| from 04 to ~10.
|
| And I remember exacty this gripe back in 2011 when Debian was
| using one network config, RHEL another. Today I actually enjoy
| the progress made with systemd, and I'm that annoying co-worker
| who will give you crap for disabling SElinux.
| jauntywundrkind wrote:
| What complaining. _There weren 't paved paths before_. Whatever
| one person learned was different from how anyone else did it.
| Few of the tools had anywhere near the essential capabilities,
| serving o ly some tiny niche of the use cases in some tool
| specific limited way.
|
| Look at all the different netsevs supported by systemd-
| networkd.
| https://www.freedesktop.org/software/systemd/man/latest/syst...
| This is a huge list of tools that required a huge assortment of
| tools to do before, few of which had even part way decent
| management & fewer still had good init scripts. You used to
| have to learn from 0 each time, with each tool. Nothing was
| alike, nothing was as capable, nothing was integrative.
|
| Don't listen to these complainers, for God sake. Your life is
| too short to get pissed off about well built work together
| featureful tools being built in a mono-repo fashion.
|
| I'm so tired of the sabotage, so tired of broadscale general
| refusenik attitudes. This post is absurd. _There was nothing to
| learn_ before, everything was 100% special snowflake &
| distinct. None of it was great, all of it was limited. Systemd
| mono-repo is built of many small pieces, but they couple
| together and are 100x more learnable. What you learn today will
| work across whatever system you run across. It's such a a
| better world, and these "pry it from my cold dead fingers"
| attitude can keep to that path for all I care, but I wish they
| weren't poisoning kinds with absurd incorrect negativity &
| being such magnets for disdain. The world today is fantastic &
| you rarely see these folks with even an iota of appreciation
| for how good we have it, never a drop of balance. But hate
| sells, & unites, powerfully.
| lupusreal wrote:
| > _so tired of broadscale general refusenik attitudes_
|
| You can use whatever software you like on your computers, but
| you're not entitled to have everybody else follow your
| choices because everybody else has exactly the same freedom
| to choose as you do. And if you want to persuade people to
| follow your lead, name calling is a bad strategy (much less
| ethnically charged name calling...)
| msm_ wrote:
| >I don't want an immutable os. (...)
|
| But I do. So I use one, and contribute to a project that tries
| to create one. Am I a part of some sub-community that wants
| constant change? Or do I just have an unusual use-case and want
| to support it?
|
| The beauty of OS is that anyone can decide which tool to use,
| contribute to it, and even fork it.
| ranger207 wrote:
| > I don't want to learn a new network config alternative with
| every update (Ubuntu changed its net config tool again with
| 24.04).
|
| That's really just Ubuntu's fault. Between upstart, Unity,
| netplan, and snapd, Ubuntu likes to go off and do its own thing
| for a few years before coming back to what everyone else picked
| in the first place
| bananskalhalk wrote:
| I was really hoping the next sudo replacement would borrow
| heavily on root as role[0] (if not being root as role). Feels
| like a missed opportunity to not use capabilities.
|
| [0]:
| https://www.sciencedirect.com/science/article/pii/S016740482...
| bandrami wrote:
| Capabilities aren't guaranteed to be present, and in a lot of
| high-security situations aren't available (though obviously you
| could say that about sudo too)
| bananskalhalk wrote:
| Sounds exciting and might be obvious, but where will I find
| systemd and not capabilities?
| viraptor wrote:
| That looks pretty good. I'm glad that the plan is to make this
| more typing friendly - systemd-run is not good enough for daily
| usage.
| pmlnr wrote:
| > The developer talks about the weaknesses of sudo, and how it
| has a large possible attack surface
|
| Poettering's hypocrisy is painful.
| mort96 wrote:
| Is it? Does systemd's sudo replacement also have a lot of
| complex code running as root in a suid binary?
|
| Because that's what he's complaining about
| jpollock wrote:
| People blame systemd for making the liblzma problem larger
| than it should have been.
|
| https://marc.info/?l=openbsd-misc&m=171227941117852&w=2
|
| "Liblzma ends up dynamically linked to sshd because of a
| systemd-related extension added by many Linux packagers that
| pulls in liblzma as an unrelated dependency."
|
| https://news.ycombinator.com/item?id=39866076
|
| "openssh does not directly use liblzma. However debian and
| several other distributions patch openssh to support systemd
| notification, and libsystemd does depend on lzma."
| deng wrote:
| So that's your best shot against systemd?
|
| - Linux packagers decide to patch sshd to use libsystemd
| for a notification, that could have been trivially done
| without this library.
|
| - libsystemd depends on libzlma
|
| - libzlma depends on xz
|
| And therefore, systemd is insecure?
|
| And what does this have to do with the fact that SUID is a
| terrible idea that needs to go?
| lmm wrote:
| > - 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 vulnerability that systems
| without systemd did not. So it certainly seems like
| systemd-the-system (not necessarily systemd-the-unix-
| process) is bad for security.
| Xylakant wrote:
| 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 attacker chose to tailor their exploit to
| those systems. Systemd was the vehicle, debian patching
| opensshd was what made this specific incarnation of the
| attack possible, but essentially, both trusted a widely
| used library.
| lmm wrote:
| > 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.
| mort96 wrote:
| My understanding is that the UNIX socket based protocol
| which libsystemd wraps for this specific feature is
| documented, stable and simple.
| tgv wrote:
| First, getting rid of setuid (I guess you'd have to get
| rid of the whole thing, not just the permission bit) is
| not the same as making systemd an integral part of the
| OS.
|
| Second, when even the package maintainers can make such
| "trivial" mistakes, something is wrong. You'd expect a
| component such as systemd to be much more trustworthy
| than some random library.
|
| I'm not arguing against systemd, just that it seems to
| grow and grow, and is not the correct place for security.
| It security is obviously broken.
| deng wrote:
| > First, getting rid of setuid (I guess you'd have to get
| rid of the whole thing, not just the permission bit) is
| not the same as making systemd an integral part of the
| OS.
|
| It absolutely is. sudo allows you to execute code as
| another user. If you want to do that without giving sudo
| itself administrative privileges, this has to be done
| through the service manager, which creates a completely
| new, elevated process and handles communication with
| that. This is how it should be done (and BTW, this is
| pretty much how also the new sudo for Windows works). Now
| Lennart for some reason prefers systemd as this service
| manager - you might disagree with that choice, but then
| come up with a better one.
| tgv wrote:
| Decoupling/single-reponsibility is sort of lesson #1 in
| software engineering.
|
| > then come up with a better one.
|
| Really?
| jononor wrote:
| Package maintainers of a distro can do absolutely
| anything to a package. With zero input from upstream
| developers. Some distros have more tradition for patching
| software than others. An upstream like systemd (or
| openssh) can hardly be blamed for what others do with
| their software.
| mike_hearn wrote:
| If it was "obviously" broken why was the xz backdoor such
| a shock to everyone? Do you personally audit the library
| dependencies of every tool you run, including core
| servers that come with your distribution? I think people
| don't do this.
|
| Also, even before the backdoor was discovered, the
| systemd team were making libxz be dynamically loaded only
| in the cases where it was needed which would have killed
| the backdoor dead. There's some evidence that this might
| have actually caused the backdoor to be sped up and hence
| led to its discovery. Claims that systemd has bad
| security have to explain why it was already implementing
| practices that would have blocked the xz backdoor without
| it even being discovered. That seems pretty decent to me.
| tgv wrote:
| The point is that (even) the systemd maintainers do not
| vet their dependencies. As an attack vector, it is the
| (second?) highest level, yet they did not assume the
| responsibility. Everybody silently assumed they did,
| hence the shock.
|
| > Claims that systemd has bad security have to explain
| why it was already implementing practices ...
|
| No, they don't. It doesn't take away the fact that they
| did not check xz, and probably only few of their other
| dependencies.
| mike_hearn wrote:
| Nobody was silently assuming the systemd maintainers were
| reviewing the source tarballs of every dependency for
| obfuscated back doors.
| James_K wrote:
| > - libsystemd depends on libzlma
|
| > - libzlma depends on xz
|
| > And therefore, systemd is insecure?
|
| Yes. You have literally just described the way it is
| insecure. It bundles a large amount of functionality
| under a single system, and therefore anything using that
| functionality is at risk. You seem to be suggesting that
| Systemd would be secure if you didn't use it, which is
| obviously fallacious. Anything is secure if you don't use
| it. Systemd offers this functionality, and did it in an
| insecure way. You cannot blame users for that. Saying
| that people shouldn't be using a certain part of Systemd
| is really the same as saying that part shouldn't exist to
| begin with. The conclusion is obviously that Systemd
| should be smaller to decrease the chances of things like
| this happening.
| Xylakant wrote:
| LZMA is a widely used compression protocol. The kernel
| uses it. xz - the compression tool that was affected gets
| used by the kernel build makefiles - they reference it in
| the build docs https://docs.kernel.org/staging/xz.html.
| It's absolutely fair from systemd to have this dependency
| and to use the trusted library that the most fundamental
| part of the underlying OS uses.
|
| It was purely the attackers choice to leverage the
| exploit via systemd instead of injecting code in the
| kernel at build time.
| James_K wrote:
| Your speculation on what is right and what was fair is of
| no consequence to me. Their error was not simply using a
| compression library, it was creating a large central
| point of failure. If Systemd was smaller, it would not
| have caused this error. By being large, it made itself
| vulnerable. It made itself a target. It made other
| software insecure. These facts are inescapable. And you
| cannot justify this by simply saying they didn't do
| anything wrong right before the attack, or that packagers
| are to blame, or that other software might also be
| vulnerable, or anything else that doesn't address the
| core of the issue: Systemd created the circumstances
| needed for this to happen. They were warned of he risks
| they created, and chose to do so anyway. Now those risks
| have been made manifest - the inevitable result of a
| fundamentally flawed design.
| growse wrote:
| Why is this an argument specifically against systemd,
| rather than all large software projects?
|
| Linux kernel, gcc, glibc - all bundle "a large amount of
| functionality under a single system" - does this make
| their design fundamentally flawed as well?
| James_K wrote:
| I think a micro-kernel architecture would be better in
| many ways, security being just one of them. With GCC, it
| couldn't really be separated into logically distinct
| modules any more than it already is. All of the
| constituent parts essentially use the full functionality
| of the base compiler part, so there is little to be
| gained separating them. It's not as if the C compiler
| from GCC, could for instance, be written in such a way
| that it doesn't depend on GCC. GLibc is a large
| implementation, but the library itself doesn't
| necessarily need to be large. There are some very small
| libcs out there.
|
| On the whole, I do not like monolithic software projects,
| but I can accept that they are necessary or beneficial in
| some cases. Systemd is simply a much bigger target than
| these other things because it is an especially bad
| example. It has many components which are only
| tentatively connected. It is also more fixable. Alternate
| init systems are used much more widely than something
| like Hurd to replace Linux. The laptop I'm typing this
| from runs GuixSD which ships without Systemd and I can
| hardly notice the difference. I doubt a different kernel
| architecture would provide such a seamless experience.
| Xylakant wrote:
| Given how common LZMA as a compression algorithm is, are
| you certain that your init system of choice doesn't use
| it in any way? It's a very common algorithm in network
| protocols, it's a direct dependency of libxml, ... - and
| if any part of your init system uses LZMA, then it just
| happens not to be affected because the attacker chose to
| target one specific system.
| James_K wrote:
| I wouldn't be affected regardless, because SSH doesn't
| depend on my init system.
| Xylakant wrote:
| The attacker had essentially full control over a very
| fundamental library in the Linux ecosystem. They could
| have leveraged that in a hundred ways.
|
| The attacker chose to target a very specific component of
| a very specific system. It was their choice, not some
| sort of technical requirement that made it impossible to
| use a different attack vector. Just as they chose not to
| target other Linux distributions that use systemd.
|
| You're essentially saying "I was safe because the
| attacker chose to ignore me." That worked well this time,
| but it's a pretty dangerous stance.
| mort96 wrote:
| What relevance does this have? Poettering's complaint is
| that sudo is way too big for a SUID binary, sshd is not a
| SUID binary?
|
| And neither Poettering nor the systemd developers patched
| said, the Debian people did that. Seems weird to blame
| systemd for that?
| jpollock wrote:
| The complaint is that the code architecture of systemd
| results in security problems for their _customers_.
|
| The inclusion of a library to send notifications
| shouldn't have external dependencies, it shouldn't need
| them. The library is included in the customer's codebase
| at execution time, so it is a hole in the customer's
| security model. This immediately opens a supply chain
| attack vector (which is what we saw).
|
| This is being taken as evidence that they shouldn't have
| responsibility for truly security sensitive code - the
| replacement of sudo.
|
| Some of this is a long-term dislike for systemd and some
| representative bias. However, Systemd has missed the
| opportunity to make their client libraries safer.
|
| Personally? I wouldn't have thought to limit the
| dependencies of my client libraries. It's a growth and
| project age thing. One moment you're on one side of a
| line, the next you have to skill up and do things
| differently.
|
| Using systemd as intended shouldn't result in security
| holes for their customers.
| mid-kid wrote:
| systemd has a lot of complex code running as root (that can
| be reached without privileges more often than not) and has
| had its fair share of CVEs.
|
| The hypocrisy is in calling out a different project for being
| an overengineered tool running with too high privileges.
| mort96 wrote:
| It's not _just_ about running as root though, but as being
| _in a SUID binary_.
| pmlnr wrote:
| The complaint might be valid. The solution, to shoehorn yet
| another functionality on systemd will in no way reduce
| complexity or attack vectors, merely shift them, again, like
| with all systemd solutions.
| kreetx wrote:
| The systemd attack vector is already there, and now the
| SUID attack vector is removed - sounds like reduction in
| attack vectors, no?
| adontz wrote:
| here's a new tool in systemd, called "run0". Or actually, it's
| not a new tool, it's actually the long existing tool "systemd-
| run", but when invoked under the "run0" name (via a symlink) it
| behaves a lot like a sudo clone.
| creshal wrote:
| But they already ship pkexec together with systemd anyway via
| polkit, why are they _again_ reinventing a wheel they already
| reinvented?
|
| Unit files are a neat concept I don't want to miss again, but
| everything else done by Lennart seems to be an inceasingly stupid
| mistake born from hubris.
| roenxi wrote:
| AFAIK privileges are an area that has an easy problem statement
| ("execute this command with that capability") and is fiendishly
| difficult to execute in practice. `sudo` alone has weird bits
| to set in the filesystem, magic users and all sorts of
| unhelpful implications - and it doesn't even lead to any
| particular security for single-user systems. Same-user code is
| a scary enough place to be running untrusted code.
|
| Those sort of problems sound like the sort that get a lot of
| attempts which run into the complexity wall and halt. I think
| Amazon has one of the best implementations of a privilege
| system I've used and it is horrible.
| deng wrote:
| Because pkexec has the same problems as sudo: it's a SUID
| binary. As Lennart says, the goal is to eventually get rid of
| SUID binaries altogether, as they are an inherent security
| risk. Replacing sudo with pkexec would not change much. In
| fact, pkexec has had its fair share of local root exploits over
| the past few years.
| eternityforest wrote:
| This seems like it won't break anything except really exotic
| scripts, I think it will probably be a good thing for at least
| the main target audience of systemd, id imagine it might
| somehow suck for others though.
| aragilar wrote:
| Uh, depending on exactly how it's implemented, it could break
| a _lot_ of things.
|
| If all you are using sudo on is a personal (i.e. single user)
| laptop/desktop to install packages, this (along with other
| things like pkexec or doas) would seem to present no issues
| (and personally, from what I can see, I'd be happy to run
| `run0` on my personal systems!), _but_ sudo does
| _significantly_ more than that, as is called out by the
| systemd devs in the linked post
| https://mastodon.social/@pid_eins/112353324518585654
|
| sudo supports not just LDAP (for multi-user systems), but
| include various levels of logging (including logging stdin
| and stdout of commands), apparmor and selinux profiles, the
| BSD and linux audit subsystem and more in a simple, easy to
| read and edit config format (this is just me reading from the
| `sudoers(5)` man page).
|
| Whereas it seems `run0` won't have a `sudoers` file, but will
| instead be configurable (implicitly) via polkit, which uses
| JS to write policies (which I'd view as a much harder and
| error-prone system than the current `sudoers` format). It's
| not clear to me how much of sudo is tied to SUID vs. having a
| separate daemon (i.e. how much would have to be ditched vs.
| how much could be mapped over).
|
| I do feel this is systemd moving away from traditional multi-
| user unix systems to being a single-user system (targeting
| the laptop/desktop case, or where sys-admins are the only
| users of the system, and it's basically a container host).
| NikkiA wrote:
| > If all you are using sudo on is a personal (i.e. single
| user) laptop/desktop to install packages, this (along with
| other things like pkexec or doas) would seem to present no
| issues
|
| Of course, once distros start to say 'wait, why are we
| shipping 3 different privilege escalation systems again?
| Systemd is needed for starting units anyway, so lets just
| drop sudo and su'
| NewJazz wrote:
| Not all distros ship pkexec with polkit. Polkit runs fine
| without pkexec present. This is kind of a non-suid alternative
| to pkexec. It's really more similar to a local-only ssh though.
| andrewstuart wrote:
| "Systemd" and "expand" used in the same sentence..... all the
| systemd haters will be triggered like it's the national rifle
| association shooting carnival.
|
| In many ways systemd has actually _become_ the operating system.
| It's so pervasive that it certainly is more deserving of naming
| rights than gnu. "Systemd /Linux" makes more sense than
| "gnu/Linux"
| blackhaz wrote:
| Mark my words, you won't be able to see the kernel anywhere in
| there soon!
| timetraveller26 wrote:
| "Systemd wants to expand to include a replacement of the Linux
| kernel" headline coming soon
| kristjank wrote:
| I am looking forward to the day systemd will implement everything
| a typical Linux system needs. No more systems greater than the
| sum of their parts, just a Half-Life 2-style Combine of Microsoft
| sponsored Poetteringware, running a monolythic system on top of a
| monolythic kernel, until systemd rewrites the Linux kernel as
| well. The future is bright! \s
|
| Seriously though, this seems to be a decent replacement for sudo
| if it works as seamlessly as it's described in the article. I
| still prefer the doas line of approach that simplifies the tool
| as much as possible, but I see the value of having such an
| important tool integrated into the existing system tooling,
| especially if it already includes everything but the kitchen
| sink.
| rahen wrote:
| I thought doas had solved this already.
| progval wrote:
| doas uses SUID
| bandrami wrote:
| It either has to be SUID or it has be a daemon running as
| root (or with enough caps to make the difference not matter).
| Adding a needlessly verbose configuration ecosystem doesn't
| change that. I imagine there's going to be some cool stuff
| this can do with homed and userctl, but it's not like the
| fundamental problem of "this program can grant root
| privileges" can ever go away.
| dale_glass wrote:
| The problem is not "this program can grant root
| privileges", it's that the setuid bit sucks.
|
| Linux processes inherit a lot of state from the parent
| which means it's absolute hell to make a secure setuid
| binary. And at any time the Linux kernel can add a new
| feature which will be inherited by a child process, but
| that the process can't defend against because it wasn't
| even a thing when the code was written.
|
| Running a binary at all also goes through a complex set of
| initialization steps a lot of programmers barely know
| exist, let alone are able to understand fully.
| bandrami wrote:
| Sure, but your choices are running an on-demand binary
| suid root, or running a persistent daemon as root.
|
| Both have problems, but if you're going to switch users
| to root you have to do one of them.
| dale_glass wrote:
| The tool doesn't try to do away with root, it tries to do
| await with the setuid bit. Meaning, "running a persistent
| daemon as root" is the intentional solution, and
| presented as the significantly better option for good
| security.
| NewJazz wrote:
| Nope, but an instance of sshd only running on localhost could
| do the trick...
| StimDeck wrote:
| Just a reminder that there are plenty of systemd-less distros
| available. Also a reminder that those distros would have been
| safe from the nearly-solar-winds-level backdooring of Linux
| distros from XZ utils.
| Jonnax wrote:
| That backdoor was never pushed out of the testing branches for
| distros.
| StimDeck wrote:
| Not sure of the relevance of this comment, can you elaborate?
| Were you the one that caught it? Our balls were inches from
| the bandsaw. Systemd made it possible to compromise SSH
| through an unrelated, single-maintainer lib that wasn't even
| a dependency.
|
| Edit: never mind, I see you are a systemd crusader.
| wpm wrote:
| Oh well I guess it didn't matter then.
| Arnavion wrote:
| It was in OpenSUSE Tumbleweed for a few days actually (RPM-
| based + rolling release + did the sshd patch). I was affected
| by it and it was fun watching the reliable ~100ms difference
| in `time /usr/sbin/sshd -h` with and without `TERM=foo`
| nialv7 wrote:
| Can you even hear what you are saying? Don't you find it
| ridiculous to blame the XZ backdoor on systemd, instead of the
| actual hacker?
|
| Even if systemd did not exist, the hacker would have just
| picked something else to infiltrate.
| bitwize wrote:
| Of course, the actual hacker was to blame, but systemd was
| implicated. The fact that the attacker was willing to settle
| for compromising just Debian and Red Hat systems indicated
| that they perceived the path from xz to libsystemd was the
| easiest way to effect the backdoor and that doing it any
| other way would have been too much work for marginally little
| gain (Red Hat and Debian systems being so common).
| pessimizer wrote:
| > Don't you find it ridiculous to blame the XZ backdoor on
| systemd, instead of the actual hacker?
|
| This is a great argument against all computer security. If
| you believe in securing your computer, you're supporting
| hackers. Because if you ever believe that a lock has failed,
| you're saying the thief is innocent; that's how logic works.
| ranger207 wrote:
| Also remember that systemd-using distros like, say, Arch were
| also safe from the nearly-solar-winds-level backdooring because
| the backdoor targeted specific distros widely used as servers.
| Obviously the solution to security from backdoors is only using
| distros that aren't popular for servers
| Iridescent_ wrote:
| Wasn't the recent liblzma attack already exploiting the fact that
| systemd has its hands in pretty much everything? Wouldn't this
| expand further the attack surface of systemd and the systems that
| connect with it?
| viraptor wrote:
| That's not a great summary of lzma. It was systems adding
| custom patch to ssh which used a systemd-related library which
| it didn't really need in the first place. It's a stack of
| issues that don't have much to do with systemd itself really.
|
| But re. expanding the attack surface - unlikely. Systemd's
| primary purpose is to start processes with the right
| environment / permissions. systemd-run/run0 basically give you
| the tool to invoke that functionality with a terminal attached
| to it. That's smaller scope of extra code than sudo/doas deal
| with.
| exe34 wrote:
| I'm surprised he hasn't started writing his own kernel by now.
| jbverschoor wrote:
| systemd operates the system :-)
| SixDouble5321 wrote:
| I think this is bang on. Let's give it more surface area :/
| rurban wrote:
| For one, a good effort by Lennart.
| mise_en_place wrote:
| sudo and su made sense when it was a multiuser time sharing
| system. You needed clear boundaries between each users of the
| system, and permission bits.
|
| If I'm running on my workstation or desktop just let me run the
| damn thing. I don't need an unprivileged user. On TempleOS you
| can modify the running system in ways you can't on Linux.
| foul wrote:
| Plan9 propaganda in the wild
| constantcrying wrote:
| Why do they have to do this? This is really, really stupid.
|
| My issue isn't even that someone tries to replace sudo. That may
| or may not be a completely fine thing to do, depending on the
| state of sudo and what improvements can be made. But what makes
| me really upset is this completely unexplainable need to make
| _everything_ part of one particular init system. There is
| absolutely no reason to tie your new sudo replacement to systemd.
| Absolutely none.
|
| This is a completely insane way to develop software, instead of
| creating a new piece of software in a separate project they will
| force all their projects simultaneously onto all their users for
| absolutely no reason.
|
| I am very glad to have jumped ship from systemd. It is
| particularly bad software created by a team of people who engage
| in very bad practices and a totally unhealthy view of software in
| general.
| dmm wrote:
| > they will force all their projects simultaneously onto all
| their users for absolutely no reason.
|
| That's just not true. Just because a system uses systemd the
| init system doesn't mean the it is forced to use the other
| components.
| constantcrying wrote:
| The single beat reason for doing this is to get a coherent
| complete system. This is what every other person here says.
|
| You can not try to create a large coherent system and then
| tell people they shouldn't use that particular part. That is
| totally disingenuous. Systemd is DESIGNED to be an all or
| nothing deal.
| growse wrote:
| > Systemd is DESIGNED to be an all or nothing deal.
|
| ^[Citation needed]
| constantcrying wrote:
| Again and again people _in this thread_ have told me that
| the great thing about systems is that it delivers
| integrated tools.
| growse wrote:
| And people are also telling you that tight integration is
| not a mandate. Having a bunch of stuff designed to work
| together does _not_ mean that they 're tightly coupled
| and can only work with their specific implementations.
|
| We've all got confirmation bias, the trick is to be aware
| of it.
| constantcrying wrote:
| This is such a bizarre statement. Of course any system
| with tight integration demands more precise
| specifications. Literally systems engineer 101.
|
| This is such an absurd hill to die on.
| logicprog wrote:
| You aren't making any sense. All of the components of
| system D are separate programs, and yes they are
| maintained by the same general project and designed to
| integrate well with each other, but just because
| components are designed to integrate well with other
| components from the same project if they are present,
| that doesn't remotely mean that all of the components are
| required. And I mean, the proof is in the pudding, there
| are plenty of distros that do not use all of the
| components of systemd. Also, doesn't Linux have a long
| history of creating integrated suites of programs
| designed to integrate well with each other and used
| together? Like GNU?
| kergonath wrote:
| A lot of people _also_ point out that "integrated" [?]
| "mandatory" and that it is not, in fact, an all or
| nothing deal.
| blueflow wrote:
| The reverse is true: Trying to use a component like udev or
| logind or in the future, run0, will require the use of
| systemd. Either you use full systemd or you can't get any of
| the fancy stuff.
|
| Gentoo folks have eudev or seatd but thats an uphill battle.
| timw4mail wrote:
| You can't take OpenRC away from me!
| dcow wrote:
| Why is this stupid? It's just an option for how to configure a
| system that uses systemd to allow commands to be run in a
| privileged execution context without a suid binary. What's
| wrong with having options?
|
| Why don't you propose a better solution? How would your non-
| systemd solution actually work?
| Starlevel004 wrote:
| > But what makes me really upset is this completely
| unexplainable need to make everything part of one particular
| init system. There is absolutely no reason to tie your new sudo
| replacement to systemd. Absolutely none.
|
| The systemd developers are tying it to systemd because they are
| systemd developers. If somebody else made something like this,
| it wouldn't be tied to systemd. But somebody else _hasn 't_
| made something like this.
|
| Sudo isn't going to just go away (unfortunately). You can keep
| using your CVE-ridden setuid binary as much as you want.
| constantcrying wrote:
| >The systemd developers are tying it to systemd because they
| are systemd developers.
|
| What? Literally every single other group of software
| developers has managed to create two projects. Even Microsoft
| can do it.
| SAI_Peregrinus wrote:
| GNU didn't. Why should Systemd?
| gkbrk wrote:
| You can use almost any GNU project without depending on
| all the other GNU projects.
| SAI_Peregrinus wrote:
| This is different from Systemd how? You can't use _any_
| GNU project without depending on GNU libc (except glibc
| itself, trivially).
| fanf2 wrote:
| userv has been around for decades
|
| https://www.chiark.greenend.org.uk/~ian/userv/
| crashmat wrote:
| noting I have been recommended doas as a more lightweight
| version of sudo so other people are trying to do this kind of
| thing
| Faaak wrote:
| I find this quite clever. Yeah yeah, "systemd is bad, it's a
| monopoly, yadda yadda".
|
| Well, there's also a reason they are doing it, and many aspects
| of it (seatd, timesyncd, resolved, run), and more neat than
| cobbling together bash scripts. I like it
| deng wrote:
| > But what makes me really upset is this completely
| unexplainable need to make everything part of one particular
| init system.
|
| It is not unexplainable at all. In fact, the article explains
| it very well.
|
| sudo allows you to execute code as another user. If you think
| about it, you could also replace sudo with ssh to localhost -
| just set a root password and allow root logins. Now, security-
| wise, this would obviously be a bad idea. Our current solution
| is to give the sudo binary itself administrative privileges,
| which is a slightly less bad idea, but still pretty bad.
|
| Systemd already handles logins, so it is quite obvious that it
| could also handle this problem very well, and in fact, it
| already does: there is a tool systemd-run which you can already
| use. It will create a completely new process and will handle
| communication to it, just like ssh, but without the above
| downsides.
| constantcrying wrote:
| >Systemd already handles logins
|
| Exactly that was my objection.
| deng wrote:
| And I disagree with that. The 'sudo problem' is a good
| example why it makes sense to handle init and login by the
| same system (note I'm not meaning "same binary" here, in
| fact, they are separate binaries in systemd). The SUID
| approach for sudo has been a problem for decades, and it
| needs to go. I don't really care if it's done by systemd,
| or if we agree on another system like S6 that was mentioned
| in another thread - in the end, they work very similarly be
| replacing the old sudo with an IPC approach.
| cryptonector wrote:
| I agree with u/constantcrying. This should not be part of
| systemd. It should be a separate service [started by
| systemd].
|
| Reasons:
|
| - systemd is a large beast -- no need to make it larger
| with unrelated things
|
| - the Unix philosophy seems to be applicable here
|
| - the result should be portable to non-systemd systems
| lugu wrote:
| The article explains how this sudo replacement ties to systemd:
|
| > But with one key difference: it's not in fact SUID. Instead
| it just asks the service manager to invoke a command or shell
| under the target user's UID.
|
| I understand your frustration, but systemd isn't the first
| attempt to build an integrated system. It just happens to run
| on Linux. It isn't insane to develop software this way, from
| that perspective.
| hxelk1 wrote:
| I've spent a lot of time studying systemd alternatives. I
| believe the overall best design is Skarnet's s6, and that too
| includes a sudo-like program:
|
| https://skarnet.org/software/s6/s6-sudo.html
|
| I was very surprised when I learned about it, but it does make
| sense (for s6 at least).
|
| > There is absolutely no reason to tie your new sudo
| replacement to systemd. Absolutely none.
|
| With s6, the idea is to replace a SUID binary with an IPC
| mechanism. That does make sense, since (parts of) the init
| system need to be running as root.
|
| > I am very glad to have jumped ship from systemd.
|
| All that aside, so am I.
| deng wrote:
| > With s6, the idea is to replace a SUID binary with an IPC
| mechanism. That does make sense, since (parts of) the init
| system need to be running as root.
|
| Same idea with systemd-run.
| Jonnax wrote:
| Is that really how they develop software?
|
| Because I'm pretty sure that most of the components are
| optional.
|
| You did not even discuss the reasoning given for not using sudo
| to instead hop on your soapbox to say it's bad software with
| bad practices and that they are stupid.
|
| It's annoying how in the the more surface level Linux
| communities there's 0 value in discussing systemd.
|
| "1 million lines of code for PID0!"
|
| The new thing is blaming systemd for that recent exploit even
| though distros were patching in the bug themselves.
|
| People analysing the exploit determined that a new version of
| systemd was going to prevent the exploit vector so the exploit
| seemed to have been rushed out.
|
| Isn't this just textbook FUD?
|
| What I've noticed is over the years is systemd would have
| identified a gap in functionality.
|
| Like systemd-homed having a solution for automatically
| encrypting home directory when the machine is suspended.
|
| Is that a functionality that OSX has had for years? Yes.
|
| But anti-systemd people will dislike it automatically.
| constantcrying wrote:
| Why are you bringing up random arguments I didn't even make?
|
| No, I am a dedicated systemd hater ever since I spend over a
| month full time writing and debugging systemd services for
| work. Systemd (the init system) is just all around badly
| designed and executed, I have very little confidence in the
| developers and their technical abilities and their tendencies
| to expand into completely unrelated areas for seemingly no
| reason makes me quite concerned.
|
| I wouldn't blame the xz exploit on them, it is very hard to
| call it their fault in any way. But I _do_ think it is a
| symptom of a system which has grown far too thin and wide.
| Jonnax wrote:
| Because your post is the repeating cliches that are under
| every discussion about systemd.
|
| You're essentially saying that the month you spent is
| enough for you to call it bad and the creators incompetent.
|
| What qualifies you to make a determination like that?
|
| There is never any actual technical reasons it's always
| about vague things like not adhering to UNIX philosophy,
| lines of code or it being badly designed (without any real
| architectural criticism)
|
| This is an article about why they believe sudo isn't a good
| system. Where's your criticism of that from a technical /
| security perspective?
|
| It's been about 10 years since systemd was adopted by
| Debian/Ubuntu/Redhat/Fedora etc.
|
| Millions of deployments over the years. The companies that
| build and are paid to support for years with SLAs the
| operating systems are using it without issue.
| constantcrying wrote:
| >There is never any actual technical reasons it's always
| about vague things like not adhering to UNIX philosophy,
| lines of code or it being badly designed (without any
| real architectural criticism)
|
| I did not mention the first two, so please do not pretend
| I argued that. For bad design look at transactions. That
| is really dumb and makes the system near
| incomprehensible. The documentation is bad, dbus is
| literally so bad they tell you not to use it without a
| wrapper. The terminology is very questionable and makes
| it hard to explain what a unit actually does.
|
| But I don't even see that as the worst part. The worst
| part is that they fundamentally can't do basic software
| engineering, in the sense that they do not have a defined
| project scope. Everything is potentially a systemd issue
| and not once does anyone take a step back and say "maybe
| systemd" isn't the right place to fix that problem.
|
| >This is an article about why they believe sudo isn't a
| good system. Where's your criticism of that from a
| technical / security perspective?
|
| If you don't read my posts please do not respond to me.
| Look at the first post I made and carefully read it.
| growse wrote:
| > If you don't read my posts please do not respond to me.
| Look at the first post I made and carefully read it.
|
| I read your OP. It does not contain a technical /
| security criticism of run0. It's an angry, hand-wavey,
| vague rant against a project that took a design decision
| you apparently disagree with, but lacking any actual
| analytical evaluation of the thing up for discussion.
|
| This sort of top-level post shows up on _every single_
| article that mentions "systemd", so you'll maybe
| understand why people tend to be dismissive.
| constantcrying wrote:
| >I read your OP. It does not contain a technical /
| security criticism of run0.
|
| Yes, I literally say there is nothing wrong with the
| idea, so you going ahead and demanding I criticize the
| idea, is just absurd.
|
| Really, this is completely bizarre. I even say that the
| thinking behind replacing sudo is fine, yet you are here
| complaining that I don't deliver technical arguments
| against something which I even told you might be
| completely valid to do from a technical perspective.
| Baffling.
| growse wrote:
| Let me get this right: you see an article on a new thing,
| which you have no problem with, but have an angry rant in
| the comments section anyway? And now you're baffled by
| people's reaction to that?
|
| I'm not sure there's much point engaging further, I hope
| you have a good rest of the day.
| constantcrying wrote:
| No, I think the systemd project shouldn't exist. I have
| no problem with someone writing a sudo replacement.
|
| Do you understand the difference?
| SAI_Peregrinus wrote:
| Do you also think the GNU project shouldn't exist? If
| not, what's the difference?
| NekkoDroid wrote:
| or OpenBSD
| yjftsjthsd-h wrote:
| I can use GNU bash on NetBSD with no other GNU software
| installed. I can install GNU coreutils on Alpine Linux
| (complete with musl libc instead of glibc). In fact, it's
| possible to just install a single part of GNU coreutils
| but not the rest - ex. Alpine packages _just_ sha512sum
| as https://pkgs.alpinelinux.org/contents?branch=edge&name
| =coreu... (not sure why). I don't think I've seen it
| done, but you _could_ build a Linux distro that used
| glibc and gcc but no other GNU software (busybox
| coreutils and ksh shell, say). GNU has their own kernel,
| but is predominantly used on other OSs. They want to
| build all the pieces, but you can opt in or out of _all_
| of them, and they 're all portable. In contrast, if you
| want to use, say, run0, you _must_ run systemd as PID 1,
| you _must_ use journald, and the whole stack only runs on
| Linux. So yeah, that is actually different.
| growse wrote:
| > and they're all portable...
|
| I think that portability is a deliberate anti-goal of
| systemd.
|
| > In contrast, if you want to use, say, run0, you must
| run systemd as PID 1,
|
| No, you must run something on pid 1 that implements the
| spec, similar to how musl can be used instead of glibc -
| they both implement the same spec.
|
| Run0 expects pid 1 to behave a certain way, much like my
| web browser expects web servers to behave a certain way.
| dale_glass wrote:
| > But what makes me really upset is this completely
| unexplainable need to make everything part of one particular
| init system. There is absolutely no reason to tie your new sudo
| replacement to systemd. Absolutely none.
|
| You should look at it differently, and then it'll make perfect
| sense.
|
| systemd has long stopped being just an init system. It's a
| system tooling suite. When thinking about systemd don't think
| "PID 1", think "Linux New System Software Suite". It's a big
| umbrella project in the style of Gnome and KDE.
|
| For example, systemd-boot is a perfectly normal bootloader
| that's just been systemd-themed. It has a "ctl" tool, has the
| same command-line aesthetics as other systemd-group tooling,
| and so on. It's not in any way dependent or even interested in
| the init system.
| constantcrying wrote:
| >systemd has long stopped being just an init system.
|
| I think that this has always been the core criticism of
| anyone who objects to them. Besides systemd, the init system,
| just being very poorly thought out.
| dale_glass wrote:
| What's poorly thought out about the init system? It's not
| perfect for sure, but on the whole I don't have any issues
| with it.
| constantcrying wrote:
| How much time have you spent writing and debugging
| systemd init files?
| dale_glass wrote:
| I've written a fair amount. Nothing much to debug in most
| of them.
| constantcrying wrote:
| Riddle me this: can I create new mount files inside a
| systemd unit and have them activated to mount the
| locations specified? Do I need a daemon reload, for this?
| dale_glass wrote:
| That sounds like a job for systemd.generator.
|
| I don't think having an unit that generates units at
| runtime is an officially supported use case, since
| generators exist.
| constantcrying wrote:
| This doesn't answer the question. Also generators are
| started very early, before other units have been started,
| so if your system is already running and now you want to
| generate those units, depending on the state of the other
| units, they don't really help.
|
| >I don't think having an unit that generates units at
| runtime is an officially supported use case
|
| Are you sure? Can you tell me how I would find out?
| dale_glass wrote:
| > This doesn't answer the question. Also generators are
| started very early, before other units have been started,
| so if your system is already running and now you want to
| generate those units, depending on the state of the other
| units, they don't really help.
|
| That's the point. Any situation in which you have a
| system modify itself at runtime is a recipe for a
| headache. So you do your auto-generation first, then work
| from a stable state.
|
| > Are you sure? Can you tell me how I would find out?
|
| Aside from that this kind of recursion seems like a great
| way to get weird problems, and that generators exist for
| this exact thing, the whole design of systemd discourages
| this kind of trickery. Units are just supposed to start a
| command and little else.
|
| Maybe somebody made an official pronouncement on this
| somewhere, but my personal take on this kind of thing is
| that it's a bad idea, anywhere, not just systemd.
| constantcrying wrote:
| >So you do your auto-generation first, then work from a
| stable state.
|
| You can't do auto generation if that generation depends
| on the output of some units. Generators _can not_ solve
| that problem.
|
| >Units are just supposed to start a command and little
| else.
|
| What a bizarre thing to say. No, that is not just what
| units are for. I think you are severely misinformed about
| what systemd is. Units are supposed to take care of
| ordering accept IPC, define how to handle failures and
| manage devices.
|
| That comment alone makes me believe that you just do not
| know what you are talking about at all. It _completely_
| misses why systemd is designed the way it is and what it
| tries to accomplish.
| dale_glass wrote:
| > You can't do auto generation if that generation depends
| on the output of some units. Generators can not solve
| that problem.
|
| True
|
| > What a bizarre thing to say. No, that is not just what
| units are for. I think you are severely misinformed about
| what systemd is. Units are supposed to take care of
| ordering accept IPC, define how to handle failures and
| manage devices.
|
| I mean that part of the point of systemd is that units
| mostly work out to ExecStart=/usr/bin/binary, and an unit
| isn't supposed to contain the arbitrary jank one can put
| into a SysV script.
|
| IPC and the like is an explicit systemd feature, not
| something you improvise behind the scenes and then expect
| to work anyway.
| rascul wrote:
| > Units are just supposed to start a command and little
| else.
|
| Units are not just for services.
|
| From systemd.unit(5) man page:
|
| > A unit file is a plain text ini-style file that encodes
| information about a service, a socket, a device, a mount
| point, an automount point, a swap file or partition, a
| start-up target, a watched file system path, a timer
| controlled and supervised by systemd(1), a resource
| management slice or a group of externally created
| processes.
| zokier wrote:
| Instead of just hating based on assumptions it would be useful
| to actually familiarize with the thing you are critizising
|
| > But what makes me really upset is this completely
| unexplainable need to make everything part of one particular
| init system
|
| systemd is not init system, its and umbrella project for
| various core system components, which includes an init system.
|
| > There is absolutely no reason to tie your new sudo
| replacement to systemd
|
| well, in this case there is good reason to have it interact
| with service manager in general
|
| > But with one key difference: it's not in fact SUID. Instead
| it just asks the service manager to invoke a command or shell
| under the target user's UID [...] Or in other words: the target
| command is invoked in an isolated exec context, freshly forked
| off PID 1, without inheriting any context from the client
|
| strictly speaking it's not 100% coupled to systemd
| specifically, it most likely uses systemds d-bus API, which is
| part of their "portable and stable" APIs and as such could be
| implemented by other service managers
| https://systemd.io/PORTABILITY_AND_STABILITY/
|
| > This is a completely insane way to develop software, instead
| of creating a new piece of software in a separate project they
| will force all their projects simultaneously onto all their
| users for absolutely no reason
|
| The couplings between systemd projects are not that tight, you
| can pick and choose which parts you want, they explicitly are
| not "forcing all their projects" to consumers. The minimal
| systemd build has only init, journald, and udev, which is not
| exactly sprawling huge. All the rest of the projects are fully
| optional, and I believe quite many of them can actually work
| without systemd-init
| constantcrying wrote:
| Half the people here tell me that systemd is great because it
| tries to create an integrated complete system, the other half
| tells me I can just pick and choose.
|
| Obviously one of these groups is lying.
| thiht wrote:
| Both can be true though, it can create an integrated system
| where everything systemd-* works together, but where you
| can replace any systemd-* you don't like with something
| else
| constantcrying wrote:
| The point of an integrated system is that interactions
| between components enhance the system as a whole. This is
| obviously incompatible with an easy replacement of
| components.
|
| This is literally just basic systems engineering. I don't
| even know what you are arguing here. The more tightly
| integrated a system is the harder it is to replace
| individual components.
| growse wrote:
| You can have a well-integrated system without having
| tight coupling between components. Interfaces are a
| thing, and a high level of integration just means having
| a good collection of interfaces between well-defined
| conceptual components with well-defined capabilities. The
| actual software that implements those components is
| entirely separate.
| constantcrying wrote:
| I don't know what you are arguing. Replacing a component
| in a tightly integrated system means that the component
| has to be compatible to that tightly integrated system,
| meaning lots of assumptions and replication of
| functionality.
|
| This means components have to tightly conform to the
| components they are replacing, which obviously decrease
| modularity as these components are harder to maintain for
| available system configurations.
|
| This isn't about whether someone can rewrite a part of
| systemd, but whether you can freely mix and match, which
| tight integration works against. _Obviously_
| thiht wrote:
| > This is literally just basic systems engineering
|
| Well... yes it is. Public interfaces and contracts,
| anyone? Decoupling?
| constantcrying wrote:
| The more tightly integrated a system is, the more
| involved the contracts between the components become. I
| seriously didn't believe that a single person here would
| disagree with that.
|
| A component that depends on one simple interface is far
| easier to replace than one which depends on twenty
| complex ones. This seems like the most basic stuff.
| wmf wrote:
| You can replace most systemd components but in that case
| you have fewer features and probably more code overall.
| If you run the whole systemd bundle you get more
| features.
| kergonath wrote:
| Replace "systemd" with "GNU" and it might be clearer (or
| "Gnome", or "KDE"). Yes, they are built to work together.
| No, they are not monoliths.
| mid-kid wrote:
| > systemd is not init system, its and umbrella project for
| various core system components, which includes an init
| system.
|
| The point being made is that it directly depends on the init
| system part.
|
| > well, in this case there is good reason to have it interact
| with service manager in general
|
| I disagree! There's no reason to not have it be its own
| daemon with its own configuration and looser bindings to the
| rest of the systemd ecosystem (e.g. through dbus and other
| protocols). KDE applications do this a lot, where they take
| advantage of other KDE components if present. This is
| strictly a philosophy thing and not a requirement for
| achieving what he proposes.
|
| > their "portable and stable" APIs
|
| "we're portable if you reimplement our APIs", idk how this is
| an argument. They consistently make very little effort to be
| compatible with (or provide fallbacks for) what's already
| there. Having stable APIs is nice but there's a reason most
| of the interfaces on that page don't have alternative
| implementations: They solve questionable problems and provide
| no tangible benefits over the methods there were before. Yet
| projects feel compelled to hard-depend on them...
|
| > The couplings between systemd projects are not that tight,
| you can pick and choose which parts you want, they explicitly
| are not "forcing all their projects" to consumers.
|
| In practice they are. The primary reason why everything is
| shipped as a single project is because that makes it easier
| to make available in different distros (they just enable
| everything), allowing it to become the "de facto" standard
| since it's available everywhere. There's a lot of projects
| that solve some of the systemd tools' in sometimes better
| ways, that never see the light of day because they don't have
| a trojan horse to ride in with.
|
| There's a reason why projects like elogind exist, because
| there's only a very select few systemd tools that work
| without systemd at all
| viraptor wrote:
| It's not unexplainable. Any init by design is supposed to spawn
| new processes with the given environment, permissions,
| capabilities. When you run "your-init-cli start foo", you're
| starting a new service process. run0 is just one step away from
| that, because it connects the terminal to that process.
|
| It's less "a new thing has been created with systemd" and more
| "a user interface was exposed for an existing functionality".
| Dalewyn wrote:
| >This is a completely insane way to develop software, instead
| of creating a new piece of software in a separate project
|
| I appreciate and respect the KISS sentiment of doing one thing
| and doing it well, but oftentimes I also think open source
| programs' lack of integration with each other at a fundamental
| level is also one of its biggest downsides.
|
| Being a Windows wizard unlike most folks around these parts,
| seeing and using the tight integrations between _all_ the
| Windows subsystems is frankly marvelous and I wish Linux could
| have something like that.
| tuna74 wrote:
| Linux is "just" an OS kernel. Integrations between user space
| programs have to be done by other people (like the systemd
| developers).
| paulddraper wrote:
| > There is absolutely no reason to tie your new sudo
| replacement to systemd
|
| It is said right there: the reason is to avoid the awkward SUID
| issues, and to have a privileged process create the process.
| immibis wrote:
| Instead you get awkward state management issues. Will the
| child really inherit everything it needs from the parent or
| has systemd forgotten to transmit something? If I chroot and
| then run0 will that process also run in the chroot? What
| about systems with older versions of systemd?
| KaiserPro wrote:
| Thats fine, and lord knows we probably need a replacement to
| sudo.
|
| However, sudo needs to be user friendly _and_ fail safe with
| decent information as to why its failed. Something that service
| files historically didn 't do.
|
| But, the way it's supported also needs to change, it almost
| certainly needs to be decoupled from systemd's release cycle.
|
| I hope that we have all learnt from early systemd, and that we
| all won't take a "lets piss on each other's chips" approach. I'm
| too old you you lot to start flame warring over stuff you'll
| never actually fucking use.
| mynameisnoone wrote:
| _doas_ exists but isn 't universally available but already
| solves this problem. _sudo_ has too many features and permits
| excessive configuration, but it also has the convenience of
| ubiquity. Inventing a third thing _tied to systemd_ is absurd
| and unnecessary.
| kbar13 wrote:
| 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 globally to the
| front of the filename". it's provided an extensible platform with
| which higher level orchestration frameworks like ansible /
| ignition can easily templatize services or other system
| configuration.
|
| since the beginning of systemd people have moaned about how
| complex it is and how we're reinventing the wheel. yet time and
| time again the people actually working on the project show that
| the solution they've come up with is the result of the problem
| they're facing on a daily basis. it's quite annoying that the
| armchair linux experts complain about how "lol systemd is so
| stupid for reinventing the wheel, give me my shell scripts back",
| maybe think about whether or not you have a legitimate issue not
| being addressed by the solution proposed or if you are just
| getting rage baited by a headline.
| dcow wrote:
| I love systemd.
| andrewstuart wrote:
| Me too. The best thing about Linux.
| jbverschoor wrote:
| It's a re-implementation of Apple's launchd. I've always
| liked it though
| bryanlarsen wrote:
| A much improved version of launchd, yes.
| freedomben wrote:
| It is much more than just a re-implementation of launchd.
| I can't grab a link right now, but Lenart wrote a long
| blog post about the philosophical decisions behind
| systemd, and he goes into detail about what he liked from
| launchd and what he did not like. It is called
| "rethinking PID 1"
| Faaak wrote:
| Yeah, basically I've found that the people the more vocal
| against systemd are either not really knowing how it works
| behind the scenes, and just criticizing for the sake of it (or
| because other people do so), or criticizing from an ideological
| point of view (do one thing and do it well). They see systemd
| as an octopus, not following the unix ideology. Which I don't
| really agree tbh
| hanselot wrote:
| Well, you don't have to understand the underlying concepts
| that deeply to know that putting all your xzs in one basket
| is a bad idea.
|
| There is no single piece of software that has given me more
| Microsoft EEE vibes in the past decade than systemd
|
| The attack vector for systemd is already enormous, but the
| inclusion of sudo seems like the most blatant attempt I've
| yet seen to put the final piece of this nation state backdoor
| in place.
| throwaway598 wrote:
| The root of the problem is sudo, and su more generally.
| This derives from *nix, or mainstream versions today,
| requiring a super user, a manifestation of the problem with
| monolithic kernals. A microkernal may be a stepping stone
| to improving this but even this is not a solution. The only
| solution is no kernal space, no privileged user(s), all
| processes negotiate independently with each other.
| metalforever wrote:
| No the root of the problem is the large attack surface
| systemd is creating by tightly coupling a ton of tools
| together, I agree about the microkernel idea completely
| though.
| dale_glass wrote:
| systemd isn't a single piece of software. It's a collection
| of software with an unified theme, like KDE or Gnome.
|
| Attack surface-wise, I don't think there's much difference
| between "sudo" being a part of the systemd package and not.
| Either way there's "sudo" code to be targeted, which
| package it's part of is just a technicality.
| SAI_Peregrinus wrote:
| I like to compare Systemd to GNU. Pretty similar scale,
| similar "take over the world" levels of adoption in Linux
| (GNU's libc is in nearly _everything_ , all the other GNU
| tools are ridiculously common), adds lots of attack
| surface to what used to be single-purpose simple tools,
| etc. Just about every criticism of Systemd applies just
| as well to GNU.
| fsflover wrote:
| https://news.ycombinator.com/item?id=40215413
| StimDeck wrote:
| Systemd mentality is what made it possible for a binary blob
| in XZ Utils to create a backdoor in SSH.
| growse wrote:
| I think dynamic linking pre-dates systemd by quite a number
| of years.
| StimDeck wrote:
| SSH being linked to XZ doesn't.
| growse wrote:
| So aim your ire at the distributions who (I agree) cocked
| this one up. "Take a library dependency to implement
| basic functionality" is not a systemd mentality, it's
| pernicious throughout software development - see leftPad
| as another example.
| immibis wrote:
| "Put everything in one big ball" is systemd mentality AND
| something that enabled the xz exploit to work.
| growse wrote:
| Lots of things enabled the xz exploit to work.
|
| If the lesson you take from xz is "systemd bad" then
| you've really missed the wood for the trees.
| immibis wrote:
| It's one of many things to consider. Think of it as
| sandboxing, or attack surface reduction. Should we expose
| everything to everything else, or should it be on a need-
| to-know basis?
| SR2Z wrote:
| Why wouldn't SSH be linked to XZ? Isn't it supported as a
| compression method for connections?
| yjftsjthsd-h wrote:
| 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.
| riddley wrote:
| xz is a compression library.
| tommiegannert wrote:
| My Ubuntu /usr/sbin/sshd already links to libz, liblzma,
| liblz4 and libzstd. I don't see why linking to libxz
| would be so outrageous. All-in-all, ldd reports 26
| libraries.
|
| They attacked the weakest link, and systemd was just a
| small pawn in that game. Sure, a smaller attack surface
| is better, but it's not like OpenSSHd has a small attack
| surface even without libsystemd. Not even in projects
| with a similar possibility of obscure "test data."
| michaelmrose wrote:
| In void it links 11 and includes only libz of the items
| you listed.
| jacoblambda wrote:
| The issue is that it's not just ideological. "Do one thing
| and do it well" is important because if you want to port
| software to another platform, it's a lot easier to port a
| single dependency component over to make it work than it is
| to port over the entire framework.
|
| This is a serious problem and it makes it way harder to make
| things cross platform.
| Xylakant wrote:
| Systemd was written specifically for Linux, hard depends on
| a list of features provided by the Linux kernel and
| leverages them to do its work. Porting it to another kernel
| is a rewrite. Lack of portability is in this case a design
| tradeoff.
| jacoblambda wrote:
| Sure that is the case for systemd itself but it's not the
| case for most projects that happen to use things systemd
| provides.
|
| There is very little benefit for most userspace software
| to tie itself to systemd and by extension linux when
| otherwise it could be portable to any unix or unix like
| platform. Especially when an alternative, portable
| solution already exists and is well established.
| fhars wrote:
| The argument was that this design of systemd makes it
| hard to write applications that are portable, so that
| systemd is effectively a very big net negative to the
| open source ecosystem, because it causes massive
| fragmentation.
| hxelk1 wrote:
| > you can actually declare startup dependencies and other
| useful relationships
|
| In theory, yes. In practice, I had a lot of trouble ordering
| things correctly in non-trivial cases.
|
| > it's quite annoying that the armchair linux experts complain
| about how "lol systemd is so stupid for reinventing the wheel,
| give me my shell scripts back"
|
| I can only speak for myself, but I don't want the abysmal
| sysvinit scripts back. I just want a simple process supervision
| suite which is true to the UNIX way of doing things. The
| sysvinit/systemd dichotomy is false.
|
| Runit and s6 are both very real alternatives to systemd. They
| lack a ton of features, but they are a way to reliably run
| services. They do use shell scripts, but not for the reasons
| sysvinit did. They are extremely simple and have a very small
| attack surface as a result. Runit itself is a spiritual
| descendant of daemontools which predate systemd by great many
| years.
|
| The problem with systemd is that it's a mediocre solution to
| many problems. UNIX deserved better.
|
| [Edit: whitespace]
| mid-kid wrote:
| In a similar vein, systems like openrc use "shell scripts" as
| well, but can generally be written declaratively[1]. This
| provides greater flexibility when it comes to creating one-
| shot services or services that require a little setup before
| running, as you can just re-define the start() function,
| rather than requiring one to make a separate shell script for
| it, or dependency tree, like you'd have to in systemd land.
|
| "sysvinit" is an ill-defined concept, anyway, as every
| distribution had their own scripts and tooling around actual
| services, and sysvinit was generally only responsible for
| starting getty and launching the distribution's actual
| service system. How initscripts were created and how you
| managed them depended significantly on the distribution.
|
| [1]: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-
| vpn/tails...
| jauntywundrkind wrote:
| The other pieces are also pretty excellent. Ifup gave me no
| joy & was very limited. Systemd-networkd is a wonderful
| option with vast & great capabilities, that meshes well with
| the init process & it's style. Systemd-timesyncd is fine, I
| dunno, works for me. Systemd-journald is probably the weakest
| of the batch but mostly because it's not very ambitious; I
| loath that there's no way to really deal with super-active
| programs hogging all the logspace, short of configuring a
| second journald instance for that program, which ain't no joy
| to setup. Systemd-home is a cool set of features for
| portability. Systemd-nspawn is a bit ahead of its time &
| looks a little weird now but was a very novel & powerful
| thing to have built in to most systems. Systemd-resolved is a
| pretty good local DNS that handles mdns and much weirder
| cases easily. Systemd-boot is a really nice easy to work with
| uefi boot loaders that's worlds easier to deal with than
| uboot or _gasp_ grub.
|
| All of these are taken em or leave em. But they're good
| expectations to have. I love the bazaar model, but Linux used
| to have so few common expectations, used to manage various
| bits so poorly. And now there's a much better base of
| capabilities, which have universal patterns of management
| that tend to apply to them (how etc files are laid how, being
| dbus and maybe varlink accessible). Linux _hadn 't_ been
| growing; when you came to a random systems you expected
| enormously little and typically got it, and what extras were
| available were scattered/random and often not particularly
| high quality or capable software. Systems has extended a much
| bigger base of competency & capability. That we can plug in a
| USB drive and systemd-home can create an isolated dynamic
| user out of that & let that user securely run their
| environment there is a neat as heck expectation. That our
| network manager supports setting up such a wide range of
| bridges and tunnels and taps and tuns is fantastic, is
| excellent. I don't have words for people turning their noses
| up at this better world; this is so much more competent &
| capable a world than where we were, gives us so much we all
| can now take for granted, and it's been done smartly, more
| mono-repo than monolithic, such that you can do alternatives.
| But many of these pieces are utterly without peer. And the
| consistency of operation you get, the predictability of use,
| from being under the same umbrella, is an ergonomic wonder
| that is unmatched.
| ghostpepper wrote:
| Is there a good overview of these pieces and what they're
| responsible for and how they fit together?
|
| I had a quick skim of the docs on systemd.io and there are
| quite a few documents but they don't seem particularly
| organized and I couldn't see a good architecture overview.
| mattpallissard wrote:
| I hate to be this guy but the man pages have it all
| man -k systemd
|
| There's some terminology to learn, but overall it's
| pretty approachable.
|
| Edit; and as far as architecture goes they are all
| _separate_ programs. It's not a single large "systemd"
| mid-kid wrote:
| I'd agree with your message if systemd was just an init system.
| bryanlarsen wrote:
| It's not difficult to use some parts of systemd without using
| others. Is it any different than something like coreutils,
| another package of linux utilities that are synergistic but
| usable seperately? Nobody complains about coreutils being
| bundled. Even the rewrite in rust crowd bundle them.
| jacoblambda wrote:
| It really is not. This "sudo replacement" (which under the
| hood is systemd-run) will apparently require quite a bit of
| the systemd stack to operate. That is not something you
| have access to in many lightweight container distros or on
| other non-systemd distros.
|
| And coreutils is expected because most people use
| GNU/Linux. Coreutils is that GNU userland part. And either
| way, the majority of coreutils are GNU implementations of
| standard unix components. You can use most software that
| depends on coreutils on other *nix platforms like BSD for
| this reason.
| bryanlarsen wrote:
| I doubt you'll need to run systemd as pid 1 to use this.
| navaati wrote:
| Oh you do: this work completely differently from sudo,
| there is no suid binary involved, instead it does IPC to
| the systemd pid 1 and asks it to spawn you process,
| attached to your current terminal. So if you don't have
| systeme as pid 1, it'll have noone to talk to.
|
| Whether you like that or not is for you to decide.
| bryanlarsen wrote:
| IPC will likely be over d-bus. The new process will fork
| off a systemd which is almost always pid 1, but it might
| not have to be.
| xolve wrote:
| Its refreshing to see that just hate systemd because "its not
| UNIX way" is not anymore. I see better discussions under this
| post and in other places around the web.
| SixDouble5321 wrote:
| Systemd isn't just one thing lol
| ranger_danger wrote:
| > systemd has been a net positive for the linux ecosystem
|
| I guess that depends on whether or not you consider the great
| number of CVEs caused by it don't matter enough.
| esoterae wrote:
| 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 didn't fork itself, which is a fish of an
| entirely different feather.
|
| And now we have this sprawling mess of complexity and headache.
| riddley wrote:
| Same thing is happening with Wayland. It reduces features
| adds complexity and solves no new problems but here it comes.
| themerone wrote:
| How is Wayland more complex than X?
| agilob wrote:
| > 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 created by logrotate with a
| date in the filename.
|
| The init system was probably peak of systemd, after that they
| started reinveting things in a more complicated way. Do we
| really need journald, systemd-boot, machinectl, systemd-
| networkd, sd-bus, systemd-resolved, systemd-nspawn? Do people
| actually use it all? Are there any metrics to show how many
| systems have it installed and in use?
| superb_dev wrote:
| The follow argument is identical to tail `-f`. `sudo
| journalctl -f -u <service name>`
| rangerelf wrote:
| And what would be the equivalent to, "Oh, I don't know the
| name of the log for this process I can see in 'ps aux', let
| me cd into /var/log and see what filenames I can find ...
| or grep everything until I can find a couple of words that
| make some sense so I can keep digging further"?
|
| The lack of explorability in journalctl, the "need" to keep
| everything locked behind their own flavor of tools and
| magic file types, is what makes the rest of us abhor them.
| iforgotpassword wrote:
| Huh, isn't grepping journalctl output pretty much the
| same? It even prefixes messages by the binary name.
| mdaniel wrote:
| Pedantically, they're the _unit_ name which only
| sometimes matches the _binary_ name
| rezonant wrote:
| Actually no, they are prefixed by the binary name and the
| PID number. Technically they are prefixed with: `<date>
| <host> <binary>[<pid>]`.
|
| You can then use `systemctl status <pid>` to identify the
| unit if you need to.
|
| I would imagine this is configurable, and this might be
| the configuration chosen by my distribution (since I have
| not changed it myself). It would actually be nice to show
| the unit name instead of the binary/PID combination,
| though not strictly necessary.
|
| EDIT: Ooh, systemd 239 adds `journalctl -o with-unit` to
| do this exact thing. There are lots of other formats you
| can choose from as well.
|
| EDIT 2: Unfortunately there's no way to set this as
| default, you must use `-o with-unit` each time or set up
| a shell alias :-\
| superb_dev wrote:
| Well `-u` refers to the unit file, so I would start with
| `sudo systemctl status` which lists the status of active
| unit files. I bet I could find the unit name I'm looking
| for there. If not, then `sudo systemctl list-units`
| should have it. (and you can grep the output of both)
|
| Systemd and Journald are less opaque than I used to
| think. Even if you don't want to learn the commands, all
| of its unit files (and the relationships between them)
| are available through the filesystem. Most of your unit
| files will be in `/etc/systemd/system`, and the active
| relationships between units are expressed through soft
| links.
| ciupicri wrote:
| # journalctl -f _PID=${your_pid} # option 1 #
| systemctl status ${your_pid} # option 2
|
| [1]: https://www.freedesktop.org/software/systemd/man/lat
| est/jour...
|
| [2]: https://www.freedesktop.org/software/systemd/man/lat
| est/syst...
| Brian_K_White wrote:
| These absolutely SUCK as answers to that question. They
| entirely miss the point. They provide a specific answer
| to a general problem.
|
| The problem with systemnd is it assumes that it's
| possible for all needs to be predicted and accounted for
| ahead of time. While "look around at directories and
| files, and grep within them" works _after the fact_
| without any special knowledge or tools. The person who
| wrote the log file did not need to know how someone will
| maybe try to access it 23 years later on a different OS.
| It 's just a regular file that can be read by anything
| over any kind of channel on any os. The person finding
| themselves needing to read the file does not need to have
| any particular command installed, or installable, or
| runnable. It does not require the happy path in order to
| work.
|
| I have a joke I always say, often self-deprecating making
| fun of my own self for the way I do things sometimes, but
| also when I'm trying to commiserate with a customer so
| they don't feel intimidated by "the expert" or "the
| engineer": "37 easy steps!"
|
| Every answer that starts with "it's simple, just
| journalctl ..." is FUCKING 37 easy steps. The very name
| of the program itself is a trainwreck. journalctl... it
| takes me 18 seconds just to type it.
|
| systemd is great for managing exquisitely washed masses
| of drone vms. It's utter and complete shit for direct
| administration, operation, development, debugging,
| flexibility, or custom integrations.
| robertlagrant wrote:
| > These absolutely SUCK as answers to that question. They
| entirely miss the point. They provide a specific answer
| to a general problem.
|
| No they don't. They are good answers. If you want answers
| to a more general problem, then ask. This is not an
| emotive topic.
| Brian_K_White wrote:
| They may be correct answers, in that they accomplish a
| task.
|
| They suck in that the proposed method for accomplishing
| the task is a suck-ass downgrade from the previous ways
| the new way proposes to displace.
|
| I beg to differ about emotive, because absolutely the
| other side of this fence behaves every bit as butt-hurt
| when challenged as I just did. You yourself just said
| these crappy commands were good, as a purely unfounded
| assertion. They are great because you just say they are
| great. That is even less objective than my rant. I at
| least explained what exactly I find so bad. Tell me more
| about not emotive.
| robertlagrant wrote:
| > You yourself just said these crappy commands were good,
| as a purely unfounded assertion. They are great because
| you just say they are great. That is even less objective
| than my rant. I at least explained what exactly I find so
| bad. Tell me more about not emotive.
|
| Very well: I didn't say the commands were good or great.
| If you attempt a little objectivity you'll see it.
| Brian_K_White wrote:
| If you attempt a little objectivity, you will see that
| addressing the answers (vs the commands) was in my first
| response.
|
| Before even going into the nature of the commands, I said
| that the answer does not match the question. The answers
| addressed details, while the details in the question were
| merely examples.
|
| Missing the point is actually merely one of the at least
| two dimensions along which the answers suck. Thank you
| for reminding me about that.
| robertlagrant wrote:
| > The answers addressed details, while the details in the
| question were merely examples.
|
| No, the answers addressed the two scenarios in the
| question. That's why they don't "SUCK". They are good
| answers to the question as asked, and not the question as
| you dreamed it. If you spent ten words on asking the
| question of your dreams, rather than having a go at
| people for not answering it (whatever it is), you might
| have an answer.
| sunshowers wrote:
| You do have to learn a few new things, yes. But it's not
| too difficult. We all have to learn new things sometimes.
|
| I spent around 15 minutes a few weeks ago learning how to
| do a few things with journalctl, and I came away from it
| with a great appreciation for its power.
| rcxdude wrote:
| systemctl status <pid> will show you the unit and
| helpfully the last few lines of log from it. Journalctl
| -u <unit name> will then show you the full logs
| JoshTriplett wrote:
| > Oh, I don't know the name of the log for this process I
| can see in 'ps aux',
|
| With services using journald, there's no "name of the
| log" because everything's in the journal, so that part
| isn't a problem. Rather than "is this in auth.log or
| syslog or thisservice.log", it'll always be in the
| journal.
|
| > let me cd into /var/log and see what filenames I can
| find
|
| You can filter journal entries by unit (-u) or by service
| identifier (-t). Often, though, I find it really useful
| to be able to see the adjacent entries from _other_
| services at the same time, since that can give some
| indication of what 's happening on the system that caused
| an issue.
|
| > or grep everything until I can find a couple of words
| that make some sense so I can keep digging further
|
| journalctl --grep, or more conveniently, journalctl and
| then / to search.
|
| > The lack of explorability in journalctl
|
| It's explorable by dozens of different axes, and if all
| of those aren't sufficient, you always can get the whole
| thing as text and run any command you like on it, or get
| it in structured form and do structured queries on it.
| hughesjj wrote:
| My 2c, I definitely prefer systemd boot+networkd, fine with
| journald, don't use the others enough to have an opinion.
| iforgotpassword wrote:
| Same. Init system is awesome, love .ini files, networkd is
| as simple as it can be, journald is fine. Love systemd-
| nspawn for simple containers as it feels more lightweight
| than docker. Especially for quick one-offs where I don't
| need isolated networking you basically have chroot on
| steroids with "systemd-nspawn -D /path/to/fstree".
| lolinder wrote:
| > 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 this time was that every single application had
| its own unique method of handling logs and its own unique
| location for storing them. So sure, once you found the logs
| you didn't have to Google how to find the relevant dates _if_
| the application is using logrotate as you describe, but
| finding the logs in the first place was always a challenge.
| Systemd is nice in that it provides a single place where all
| logs go and a single interface for navigating them.
| saghm wrote:
| > journalctl supports -f, which by your own account you
| were already using for tail, so I'm not clear what's worse
| there
|
| Yeah, this is a bit of an odd complaint. If I were this
| bothered by having to type those, I'd just make an alias to
| "journalctl --follow --nopager"` and would have forgotten
| about it years ago.
| stoperaticless wrote:
| Never tried it, but if the complainer wrote: tail -f
| *.logs
|
| Which involves glob'ing. I assume it allows to monitor
| several services at the same time.
|
| Can systemd do that?
| tapoxi wrote:
| Yes, journalctl -u postgres -u redis -f etc
| mintplant wrote:
| Or just `journalctl -f` to follow all logs.
| _flux wrote:
| It's the basic function what journalctl -f does by
| default: follow the global log all jobs write into. -u
| etc are for filtering that.
| mdaniel wrote:
| > I'd just make an alias to "journalctl --follow
| --nopager"` and would have forgotten about it years ago.
|
| You sure would have forgotten about it when you tried to
| get onto another machine without the magic set of aliases
|
| I am also prepared for someone to chime in that "log
| egress tools exist" to move up the Maslow's Hierarchy of
| Log Needs
| cogman10 wrote:
| I think my biggest gripe with journalctl is (and this may
| just be because I'm novice at using it) that discovering
| what sort of logs are on the system feels a lot more
| complex.
|
| With regular logs, I can go to /var/log, ls the dir, and
| get a nice list of what's being logged. There will be, for
| example, an `apache.log` file that has all the logs
| relevant to apache.
| tapoxi wrote:
| It's just journalctl -u apache -f, assuming your
| distribution calls the unit file "apache", and the last
| few messages of the logfile appear with systemctl status
| apache
|
| And you don't need to worry about "is this service
| rotating logs appropriately?"
| cogman10 wrote:
| The important thing for me at least isn't he `-u apache`
| but rather knowing that `apache` exists as one of the
| installed services on this box.
|
| In the old ways, that was apparent because of the
| presence of the log file.
|
| Granted, this isn't the problem it used to be for us,
| however, it would come up because we'd have our services
| named things like `foo-ws` and knowing that `foo-ws`
| existed on a given box might be tricky were it not for
| the log files.
| tapoxi wrote:
| I mean "systemctl status" shows all services and their
| hierarchy, there's also "systemctl list-unit-files" if
| you want to see things that aren't part of the current
| target (runlevel).
|
| It's much easier in the systemd world to see the state of
| the system, the state of the service, and the logs of a
| service because it enforces this consistency.
| cogman10 wrote:
| Ah, good to know. I figured it might be the case that I
| just needed to RTFM.
| tadfisher wrote:
| journalctl -f -u <TAB>
|
| Shows you all installed units if you have working shell
| completion, or 'a<TAB>' gets you all units starting with
| 'a', etc.
| kbar13 wrote:
| honestly that's such a niche problem to have that i dont
| think it's worth throwing the baby out with the
| bathwater. anyways you shouldn't be discovering installed
| services by logfile presence, it should be something like
| querying your package manager.
| cduzz wrote:
| 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 improvement, and I'm
| not even really 100% sure that this new "inflate and snap"
| shoe model is actually an improvement, except for very
| specific use cases.
| acdha wrote:
| 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.
| Asmod4n wrote:
| Oh the joy it is to have a corrupted log file which the
| program that wrote it refuses to even read.
|
| Once you deal with that you'll realize journald is just in
| the way and needs to be modified to output a human readable
| log by default.
| citrin_ru wrote:
| '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.
| rezonant wrote:
| While I'm very pro journalctl, this is very true. They
| should put some work into the initial read performance on
| big journals.
| jordemort wrote:
| systemd-nspawn is actually pretty great, and is mostly just a
| tool that exposes functionality that systemd already needs
| for other reasons. IIRC it was originally developed to aid in
| testing systemd itself, and was initially shipped as an
| unsupported extra in case other people found it useful.
|
| systemd-resolved is the only way I've ever been able to get
| dockerd to play nice with Tailscale DNS; it's also the best
| way that I've found to get a system to pick different
| upstream DNS servers depending on domain. The alternative is
| hand-rolling it with dnsmasq or something similar.
|
| I admit I haven't really seen a huge advantage to using
| systemd-networkd over NetworkManager yet, but for servers
| with relatively static network configurations, I greatly
| prefer systemd-networkd over any of the various
| implementations of ifupdown.
| sunshowers wrote:
| 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!
| rezonant wrote:
| Ooh nice. What are some examples of things it will catch?
| dumpsterdiver wrote:
| My goto is journalctl -xf. Best of both worlds :)
| aeonik wrote:
| How does it work? Can I pipe non-journald logs into the -x
| flag to take advantage of this lookup?
| rezonant wrote:
| > This was a really big pain, yes, but I also remember how I
| could `tail -f *.logs`.
|
| Others point out that journalctl supports `-f` and `-n` for
| determining how much journal to return, but for me what's
| great about journalctl is that _I do not need to know_ where
| the program is logging to, how it rotates logs (or how it
| doesn 't), or anything else. The program does not need
| special permissions to a log location in /var/log or
| /usr/var/log or ~/... or anything else, it just outputs using
| stdout and it gets captured. When I want to look at logs, I
| just use the same moniker that I use to control the service:
| its unit name. It is so incredibly nice- I do not want to go
| back to the bad old days of spelunking through /var/log and
| friends.
|
| > --no-pager
|
| To be clear, if you pipe journalctl somewhere, it will
| automatically skip the pager and just work. `--no-pager` is
| most useful for when you want to print some unpiped content
| in an automated script to avoid having a non-existent user
| exit the pager.
| ranger207 wrote:
| I remember, and sometimes still have to deal with, programs
| that _didn't_ dump their logs in /var/log, forcing me to
| figure out where the log are in the first place
| paulddraper wrote:
| 100%
|
| Systemd unit files make Linux feel like a rational OS.
| slackfan wrote:
| Only if your marker for a rational OS is NT.
| delta_p_delta_x wrote:
| Not the parent commenter. Windows has a lot of rubbish
| user-level interaction which belie how good an OS NT really
| is. Anyone who blindly disses it because 'Windoze' and 'M$
| bad' is not really worthy of any attention whatsoever.
| slackfan wrote:
| NT isn't terrible with some very well designed systems,
| that is quite true. It is however good for a completely
| different list of reasons that *nix is. Trying to
| conflate the two is a pottering's errand.
| aftbit wrote:
| Ah yes I remember back when you just put the system hostname in
| /etc/hostname. Now we have hostnamed!
| egorfine wrote:
| Which is now borderline impossible to tame. Google "change
| hostname ubuntu" and take a look at the results and comments.
| bitwize wrote:
| I don't resent systemd for existing, but I don't want to be
| forced to accept Lennart's shitty design decisions and it's
| clear he wants me to be since he successfully agitated for
| other critical components to hard depend on it. I want the
| option of opting out, which Lennart would deny me if he could.
|
| At the end of the day, I just run Void (or MX Linux if I want
| something more Debian-flavored) and get on with my life.
| foresto wrote:
| > systemd has been a net positive for the linux ecosystem.
|
| You're presuming to speak for an awful lot of people there, on
| a topic that would be difficult to measure.
|
| > since the beginning of systemd people have moaned
|
| > it's quite annoying that the armchair linux experts complain
|
| Now you're overgeneralizing, and doing so in a dismissive and
| patronizing way.
|
| Here are a few examples of problems I have with systemd:
|
| System shutdown/reboot is now unreliable. Sometimes it will be
| just as quick as it was before systemd arrived, but other
| times, systemd will decide that something isn't to its liking,
| and block shutdown for somewhere between 30 seconds and 10
| minutes, waiting for something that will never happen. The
| thing in question might be different from one session to the
| next, and from one systemd version to the next; I can spend
| hours or days tracking down the process/mount/service in
| question and finding a workaround, only to have systemd hang on
| something else the next day. It offers no manual skip option,
| so unless I happen to be working on a host with systemd's
| timeouts reconfigured to reduce this problem, I'm stuck with
| either forcing a power-off or having my time wasted.
|
| Something about systemd's meddling with cgroups broke the lxc
| control commands a few years back. To work around the problem,
| I have to replace every such command I use with something like
| `systemd-run --quiet --user --scope --property=Delegate=yes
| <command>`. That's a PITA that I'm unlikely to ever remember
| (or want to type) so I effectively cannot manage containers
| interactively without helper scripts any more. It's also a new
| systemd dependency, so those helper scripts now also need
| checks for cgroup version and systemd presence, and a different
| code path depending on the result. Making matters worse, that
| systemd-run command occasionally fails even when I do
| everything "right". What was once simple and easy is now
| complex and unreliable.
|
| At some point, Lennart unilaterally decided that all machines
| accessed over a network must have a domain name. Subsequently,
| every machine running a distro that had migrated to systemd-
| resolved was suddenly unable to resolve its hostname-only peers
| on the LAN, despite the DNS server handling them just fine.
| Finding the problem, figuring out the cause, and reconfiguring
| around it wasn't the end of the world, but it did waste more of
| my time. Repeating that experience once or twice more when
| systemd behavior changed again and again eventually drove me to
| a policy of ripping out systemd-resolved entirely on any new
| installation. (Which, of course, takes more time.) I think this
| behavior may have been rolled back by now, but sadly, I'll
| never get my time back.
|
| There are more examples, but I'm tired of re-living them and
| don't really want to write a book. I hope these few are enough
| to convey my point:
|
| Systemd has been a net negative in my experience. It has made
| my life markedly worse, without bringing anything I needed.
| Based on conversations, comments, and bug reports I've seen
| over the years, I get the impression that many others have had
| a similar experience, but don't bother speaking up about it any
| more, because they're tired of being dismissed, ignored, or
| shouted down, just as I am.
|
| I would welcome a reliable, minimal, non-invasive, dependency-
| based init. Systemd is not it.
| frafra wrote:
| This is not new functionality:
|
| "There's a new tool in systemd, called "run0". Or actually, it's
| not a new tool, it's actually the long-existing tool "systemd-
| run", but when invoked under the "run0" name (via a symlink)".
|
| systemd-run is very useful to run tasks with specific cgroups
| settings, or at a specific time. It asks for password whenever
| needed.
| mehdix wrote:
| Lennart's toots suggest they are replacing a complex SUID binary
| with an already existing component (systemd-run) with better
| workflow (service manager handling the elevated context), which
| sounds like a sane move to me.
| gpderetta wrote:
| Does systemd read email yet?
| ezoe wrote:
| I wonder what other existing programs Will Systemd attempt to
| replace in the future.
|
| My bet is /bin/sh, maybe they went further to replace the entire
| POSIX utilities.
| anthk wrote:
| Guix will reimplement POSIX utils and extras with tools written
| in Gule.
| smegger001 wrote:
| Please say this is a joke
| anthk wrote:
| https://nlnet.nl/project/Gash/
|
| It wouldn't be a bad idea. Also, Guile's JIT could be
| interesting there.
|
| Also, a shell with a live REPL instead of _failing_ on
| errors can be pretty interesting.
| quectophoton wrote:
| filesystemd, replacing ext4/btrfs/etc.
|
| It will come with `filectl` for all your file operations, so
| you will no longer need `cd`, `pwd`, `touch`, `rm`, `mkdir`,
| `cat`, `grep`, `find`, etc. Instead you do everything through
| `filectl` commands.
|
| This will deprecate many commands from GNU coreutils, which is
| a good thing because replacing things is always good.
|
| Then, since programs are just files, and filesystem will be
| part of systemd, any program you want to use will obviously
| have to go through systemd as well, meaning they will need to
| be a service unit of type `oneshot`, because this way we keep
| everything well integrated together.
|
| Don't worry tho, you only write the unit files once and they
| work forever. The only thing you need to remember is that,
| instead of `cargo build` you'll need to use `filectl exec -u
| cargo build` (`filectl exec -u` is only 3 words, so you don't
| have the right to ever complain about this tiny little change).
|
| Anyone who doesn't like these changes is stuck in the past.
| foresto wrote:
| > instead of `cargo build` you'll need to use `filectl exec
| -u cargo build`
|
| You joke, but I already have to do this with lxc commands,
| and the systemd-compatible version of those commands is even
| longer than you imagined. See my other comment for details.
| sys_64738 wrote:
| How long before humans are systemd compatible?
| segasaturn wrote:
| This is very interesting, can somebody explain what this is and
| how it's different from executing through sudo? The LWN post
| links back to Lennart's Mastodon which in turn is a big pile of
| toots (ugh) in the wrong order
| immibis wrote:
| This will be great. We can finally deprecate sudo on systemd
| systems. Then we should be able to deprecate PAM, setuid bit,
| etc.
| yjftsjthsd-h wrote:
| I can see creating a system with zero setuid files, but I don't
| think this reduces PAM use, does it?
| eichin wrote:
| Not setuid generically, but `sudo` itself has a bunch of pam
| support/dependency.
| yjftsjthsd-h wrote:
| I would expect sudo to also touch pam a lot, but AIUI
| systemd _also_ uses pam through polkit for its ~native
| permission system -
| https://serverfault.com/questions/841306/authentication-
| is-r...
| cedws wrote:
| I wonder, are there any distros already with a nosuid root?
| Retr0id wrote:
| Is removing setuid actually a win? I know it presents a
| security risk, but it feels like we're not actually removing
| that attack surface, just moving it around.
| NekkoDroid wrote:
| Well... that "attack surface" isn't new, its mostly just
| repackaging systemd-run, which is just used to tell PID1 to
| launch a new process. So in total the attack surface would be
| reduced by removing sudo.
| kevincox wrote:
| > One could say, "run0" is closer to behaviour of "ssh" than to
| "sudo", in many ways.
|
| This is an interesting offhand comment. You could implement a
| very similar tool by SSHing to localhost.
| __s wrote:
| Indeed, there was a blog by a redhat engineer doing that:
| https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket
| Arnavion wrote:
| 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.
| pmontra wrote:
| 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.
| noinsight wrote:
| You can just use `-i` instead of `bash`. (This method
| indeed requires a shell configured, your method is needed
| with nologin.)
| yegle wrote:
| In my previous job, we set up a privileged account on a server
| with shell set to `git-shell`, leave some shell scripts in
| $HOME, so that we can do:
|
| > ssh user@privileged-commands ./do-something
| m463 wrote:
| I had to write an ssh client for an embedded system long ago.
|
| Looking at the design, I found it to be sort of messy.
|
| You could restrict commands ssh could invoke, but it didn't
| seem super secure.
|
| Also scp/sftp was not well designed. You basically had to give
| ssh access to your system to allow a file to be copied, and
| there were no real path restrictions.
|
| I personally thought ssh could be much more robust in what you
| could run and what you couldn't. And scp/sftp could have better
| filesystem semantics so you could have more security in what
| you could access.
|
| And I thought having a write-only scp would be really
| interesting, sort of like a dropbox for people to send you
| files securely, but not have to give someone ssh credentials to
| do it. And an anoymous scp/sftp for distribution or a dropbox
| could have been really interesting too.
| fn-mote wrote:
| Overall, this seems great.
|
| However...
|
| > [...] by default it will tint your terminal background in a
| reddish tone while you are operating with elevated privileges
|
| ?!! ouch ... seems orthogonal to the actual important parts.
|
| Disclaimer: I didn't try it.
| NekkoDroid wrote:
| I tried it a bit ago (when it was still called uid0, pre-
| release), I also wasn't a fan of the tinting.
|
| I like the intent behind it, but some terminals already tint
| the header color when running sudo, I haven't tested if its
| done specifically for sudo or if its in a more generic way that
| could handle this as well.
| Karellen wrote:
| > I also wasn't a fan of the tinting.
|
| From the linked mastodon thread:
|
| > For example, by default it will tint your terminal
| background in a reddish tone while you are operating with
| elevated privileges. That is supposed to act as a friendly
| reminder that you haven't given up the privileges yet, and
| marks the output of all commands that ran with privileges
| appropriately. _(If you don 't like this, you can easily turn
| it off via the --background= switch)_.
|
| (emphasis mine)
| gh02t wrote:
| It was a bit unclear to me from the thread, is there a
| persistent configuration option for this? I like the idea
| of tinting the terminal, but I also want to be able to turn
| it off with a global config option rather than having to
| type out a --background flag every invocation.
| zamadatix wrote:
| Aliasing the command as the command + your default
| arguments is the easiest general solution to this kind of
| problem. I'm not sure if there is a "systemd way" to
| permanently set it though.
| gh02t wrote:
| True, I was thinking a simple environment variable or
| systemd configurable would be fine but I guess an alias
| is a good idea.
| tolciho wrote:
| I accidentally compile color support out of st, or set
| xterm*colorMode:false to avoid seeing the backside of a
| unicorn randomly rubbed all over the terminal, on account
| of git and other wares being bad at their inability to
| not spew color codes. A sensible default would be to set
| no colors, in the event that the colors are unreadable
| (due to colorblindness, etc) or distracting, but that
| ship sailed. Most of my vim config on RedHat linux was
| disabling wacky vendorisms, and back when I used linux I
| did have a "special terminal" for some NVIDIA installer
| that mandated colors to be usable. Maybe the terminal
| title was set to Fisher-Price, maybe not.
| zamadatix wrote:
| I think it's more that the default seems backwards than the
| lack of ability to change it.
| dsr_ wrote:
| 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
| zamadatix wrote:
| "Defaulting to on" is just a symlink to an existing
| binary so that's not really much a problem.
| deadbunny wrote:
| I for one love to type out 13 extra characters to a 4
| character command to disable dumb choices by the developer.
|
| On a more serious note, I wonder what random ASCII escape
| sequences we can send.
| withinboredom wrote:
| I can think of a number of things this tinting would break.
| lupire wrote:
| Can you name any?
| dsr_ wrote:
| The user's choice of color schemes.
| shiomiru wrote:
| If the program you're running prints red text, then you
| get red bgcolor with red fgcolor. Good luck reading that.
|
| (Also, users with the wrong color scheme get that
| experience by default. Though that is a niche use case
| enough that I'd be shocked if systemd devs cared about it
| - after all, they couldn't even bother to respect my
| PAGER env var.)
| seanc wrote:
| It violates the principle of Least Surprise; if I'm
| invoking run0 I'm expecting it to run my program with a
| different UID and return the same stdout I'd have gotten if
| I had just run the program in my shell. Not inject a whole
| bunch of color control bytes in there. Which hopefully my
| terminal will handle. Unless it doesn't.
|
| I'll give them the benefit of the doubt and assume they
| only do this if $TERM supports color. But still. That $TERM
| variable can surprise a poor programmer in all sorts of
| ways.
| bityard wrote:
| This is a perfect example of a choice that a developer makes to
| suit his/her personal preference and environment, believing
| that everyone does (or should) use their computer the same way.
| Which is sadly becoming a more common trend.
|
| I like the idea, but I don't think it should be on by default.
| The rest of us have just used root-specific shell prompts for
| the last few decades or so.
| TZubiri wrote:
| It's fine.
|
| Not every software needs to be infinitely configurable and
| open source just in case the configurations don't cover the
| needs of all.
|
| We need opinionated software, if you don't want to make any
| choice for me, you can't even give me an assembly editor for
| fear of forcing your CPU arch of choice.
| shrimp_emoji wrote:
| Counterpoint: GNOME and the modern GTK framework
|
| (I needn't say more.)
| yoyohello13 wrote:
| Gnome is great if you're willing to do things their way.
| I Like Gnome a lot actually.
| akagusu wrote:
| Piece by piece, Red Hat is taking over the Linux ecosystem.
| cozzyd wrote:
| Ironically enough, Lennart now apparently works for Microsoft.
|
| (though to be clear, I like systemd and I think Lennart is a
| very good engineer).
| oceanplexian wrote:
| That's a great fit for him since systemd appears to lift
| their monolithic design practices and force them on the Linux
| community.
| izacus wrote:
| Well, they're the only ones actually funding development of the
| ecosystem, aren't they?
|
| The rest just do a lot of opinoning and complaining and not
| that much of developing.
| superkuh wrote:
| The implicit premise of this comment is that linux is broken
| and needs to be changed. It isn't. The changes are not
| inherently good. Development is not inherently good. Just
| look at Gtk3 from 2014 to 2024. It was far more functional in
| 2014 (re: keyboard input) and now that has been removed
| because "progress".
| throwaway11460 wrote:
| Nobody needs to adopt the changes. Everybody did because
| it's better than the alternatives. There are still systemd-
| less distros if you like it.
| superkuh wrote:
| My issue is not with systemd. My issue is with the
| argument that all development is good. In this example I
| am pointing out how Gtk3 has suffered from development
| attention from GNOME over the last decade and became
| worse.
|
| Maybe run0 is worse than sudo. Maybe not. I have no
| personal experience on that topic and I doubt anyone here
| does.
| throwaway11460 wrote:
| It's the same thing though - nobody is forced to accept
| their changes, you can fork at any time. Or stop using
| it, keep using gtk2, etc.
| immibis wrote:
| Reality is more nuanced than that, because even if the
| newer software is worse, if it markets itself better it
| can persuade other projects to drop support for the old
| software.
| thecrash wrote:
| Yes, theoretically we could just stick with old software
| that was perfectly good at the time. The problem is that
| the ecosystem moves together - there's an emergent
| consensus about what is "current" (i.e. what's obligatory
| to support) across many different projects.
|
| So each component is interrelated, and holding one back
| means sacrificing compatibility with the new features
| (and security fixes!) of many other components.
|
| In this way we can find ourselves dragged into using
| software that is actually worse than it used to be. This
| is important to note because it means our use of a
| component is not proof that it's good. It just means that
| the ecosystem is good enough _overall_ that it can force
| us to accept devolved versions of certain components.
|
| It makes sense to argue about what the consensus of the
| ecosystem should be even while recognizing that we will
| probably accept it regardless.
| sophacles wrote:
| No one is stopping you from running a 2014 version of your
| favorite distro. Seems like a good way to address your
| concerns.
| superkuh wrote:
| Indeed. I have been using Ubuntu 14.04 under ESM for the
| last 10 years. But that ESM support is ending in 2024.
| I've tried modern distros using modern Gtk3 and they're
| lousy with file chooser bugs. I've tried patching Gtk3
| gtkfilechooserwidget.c myself but I can only fix it for
| the first file->open dialog, not subsequent ones.
| Attempts to get help in #Gtk over the last 5 years have
| been rebuffed in IRC and ignored/closed repeatedly on the
| issue trackers:
| https://gitlab.gnome.org/GNOME/gtk/-/issues/5872
| Spivak wrote:
| I guess but in this case it's doing something that sudo doesn't
| do -- get privs from a daemon instead of setuid, and using
| something that systemd already did (systemd-run).
|
| Is it that weird that they would make a runas frontend when all
| the pieces of it were lying around?
| immibis wrote:
| We don't have to use their stuff. systemd actually does a good
| job of managing services' up and down state - it's the rest of
| the bundled functionality that people take issue with - and if
| service up and down is all you want, there's runit.
|
| Wayland seems to be a solution without a problem, and it's only
| winning by default. I've toyed with the idea of forking Xorg -
| the code is a bit odd by today's standards, but I didn't find
| any direct _problem_ with it, and it works fine - the biggest
| problem I discovered in Xorg is a lack of _project management_
| as nobody knows what it should and shouldn 't do
|
| My gentoo system has some gentoo-specific fork of udev without
| systemd in it.
|
| We don't have to use run0 and can just use sudo.
| segasaturn wrote:
| I asked this in a thread about this from last night and didn't
| get a reply. For context, the way "run0" works is to apparently
| send a signal to polkit that requests a command under the root
| user's ID and permissions, thereby getting a privileged shell
| without SUID:
|
| > How hard would it be to create a program to send a signal to
| polkit "impersonating" run0 and obtain a root shell without
| entering a password?
|
| Anybody know how this is being authenticated?
| ongy wrote:
| Without looking at the he specific implementation
|
| There should be a service running as uid=0 that exposes an
| unprivileged API.
|
| This service then takes the RPC and does authorization with
| polkit.
|
| I.e. the unprivileged part doesn't talk to polkit directly. But
| a privileged part uses polkit instead of a custom sudoers style
| config.
| thayne wrote:
| I would assume the authentication happens in polkit, so a fake
| client would only be able to run a command if it had the
| necessary credentials.
| StayTrue wrote:
| Perhaps the nomenclature should be updated from GNU/Linux to
| GNU/systemd/Linux.
| phone8675309 wrote:
| Until systemd consumes the kernel and then it will be
| GNU/systemd
| CamouflagedKiwi wrote:
| Or it consumes every other part of the GNU runtime and it
| becomes systemd/linux
| bitwize wrote:
| https://www.tumblr.com/wizardofbits/96856361060/rethinking-t.
| ..
|
| Waiting for this to no longer be fake.
| abridgett wrote:
| 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).
| cozzyd wrote:
| sure but very few people (relatively) are doing stuff like
| that?
| lupire wrote:
| What's the goal?
|
| If the host is to get most scenarios off sudo, exceptions
| aren't a problem.
|
| If the goal is to delete sudo, exceptions matter, and migrating
| what is migratable will clarify what the remaining requirements
| are.
| stop50 wrote:
| Thats why i moved every sudoers rule to ldap. Much nicer to
| configure and no need for files with the same content on
| multiple servers. New users are added and removed fast and i
| can check the rule on any server.
| agwa wrote:
| 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...
| akira2501 wrote:
| If the lesson of xz was "reduce supply chain attack surface"
| then the freedesktop people clearly haven't received it yet.
| rcxdude wrote:
| 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.
| westmeal wrote:
| what else is systemd going to eat :/
| atoav wrote:
| It would be really funny if systemd tried to replace
| pulseaudio.
| Narishma wrote:
| pulseaudio is already in the process of being replaced by
| pipewire.
| figomore wrote:
| Pulseaudio was created by Lennart Poettering.
| withinboredom wrote:
| I don't understand the point of creating an entirely new shell
| inheriting almost nothing. Seems like that would cause a lot of
| issues (i.e., sudo make install)
| Arnavion wrote:
| That's how sudo already works on most (all?) distros. Eg Debian
| 12 has: Defaults env_reset
|
| ... which will clear almost everything that `make install`
| would've used. OpenSUSE TW has: Defaults
| always_set_home Defaults env_reset Defaults
| env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE
| LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY
| LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL
| LANGUAGE LINGUAS XDG_SESSION_COOKIE"
|
| ... which is a lot more, but will still clear whatever `make
| install` would've used.
|
| Anything you need to give to `make install` should be given
| explicitly, like `sudo make INSTALL_ROOT=$INSTALL_ROOT install`
| or whatever.
| gcbirzan wrote:
| If you're using autoconf/automake, you don't need to do that.
| throw0101b wrote:
| First comment at the LWN:
|
| > [...] _I think calling the flags "setuid" (as lwn appears to
| prefer?) just blurs things, since that's the name of a syscall
| (setuid()), which does something related, but is not actually
| involved in the concept that the inode SUID flag is about._
|
| > _Hence, I am a bit confused what that comment here is supposed
| to achieve? It just creates confusion?_
|
| > _Lennart_
|
| * https://lwn.net/Articles/971747/
|
| Reply by corbet:
|
| > _Lennart, the purpose was to be sure that readers knew what the
| term meant in the quote, nothing more._
|
| Never change, Lennart, never change...
| mzs wrote:
| the right person to replace sudo, not:
| https://github.com/systemd/systemd/issues/6237
|
| PS: https://pwnies.com/systemd-bugs/
|
| edit, this one went on for more than a year:
| https://github.com/systemd/systemd/issues/6632
| dang wrote:
| Url changed from
| https://www.osnews.com/story/139490/run0-a-systemd-based-mor...,
| which points to this.
| jmclnx wrote:
| Why ? I guess you do not get this unless you have systemd, that
| is fine by me. If I would use anything outside of sudo I would go
| to doas.
|
| My home distro does not have systemd, so I guess I may never see
| run0.
|
| I have been evaluating the various BSDs for a few years in case
| my distro is forced to use systemd and friends. The distro I use
| is fighting the good fight against large monolithic tools, but it
| is having a hard time trying to avoid these monolithic tools.
|
| With Linux slowly forcing systemd, Wayland, various Desktop
| Environments and now this, my move to a BSD may happen sooner
| that later.
|
| Curious, I wonder how close run0 is to how Windows raise auths ?
| With LP now working for Microsoft, is he cloning tools from
| Windows for use in Linux ?
| mise_en_place wrote:
| This is just a complete disaster. Ever since libxz has shown how
| bloated and spaghetti code systemd is, now they want to make it
| seem like they're going to have "security" in mind. What a joke.
| mzs wrote:
| https://github.com/secnigma/CVE-2021-3560-Polkit-Privilege-E...
| bhaney wrote:
| Is it "run-zero" or "run-oh"?
| cesaref wrote:
| Let's assume for a moment that it is lower risk than sudo (which
| is the problem is it addressing), why isn't it also called
| 'sudo', designed to behave the same as the thing it is replacing,
| so that anyone (and any scripts) that currently use sudo can
| carry on and be oblivious to the security benefits this new
| implementation offers?
|
| I'd instead like to see a post saying something like 'on systemd
| based systems, a more secure implementation of sudo is provided',
| and all the clever whatever it is happens behind the scenes, and
| frankly i'll never need to know about it.
| agilob wrote:
| Because there already is jq-go and jq-python. One of them is
| called jq in linux the other is called jq in MacOS. They are
| not compatible and you find out you're using the other one
| after 6 hours of screaming at the computer.
| voiper1 wrote:
| calling it sudo would create the expectations that all the
| options, config, and usage is exactly the same.
|
| It would appear that it's _functionally_ the same, but using a
| different mechanism and with a new name so they don't want to
| be locked down to all the other stuff.
| zzo38computer wrote:
| Presumably because it uses different options and other
| different stuff, it has a different name. However, it might be
| useful to have a command "sudo" which emulates the options of
| sudo so that you can still use the same "sudo" command on
| systemd-based systems as well as on non-systemd-based systems.
| I don't really know how well that would work, though.
| SkyMarshal wrote:
| alias sudo="run0"
|
| If run0 supports the same flags and parameters they'll be
| interchangeable with just an alias.
| anonymous_union wrote:
| holy shit this guy knows no shame
| tommiegannert wrote:
| This is playing on the difference between hoping that sudo does
| the right thing juggling setuid and capabilities, and having a
| strict IPC boundary between privilege levels.
|
| It sounds like a great use of systemd, for those who want to use
| it.
| nan60 wrote:
| Guess it's time for me to switch to Void...
| slackfan wrote:
| Nope. I trust this about as far as I can throw it, and I will
| continue editing my own files.
|
| If I want NT, I'll just run an NT-based OS, thanks.
| airocker wrote:
| I have seldom come across unix multiuser environments getting
| used anymore for servers. Its generally just one user on one
| physical machine now a days. I understand run0's promise is still
| useful but i would really like to see the whole unix permission
| system simplified for just one user who has sudo access.
| rpgwaiter wrote:
| NixOS may be helping multiuser make a comeback, at least it is
| for me and my home servers. I no longer have to containerize my
| apps, i can have one baremetal server with a dozen+ services,
| all with their own users and permissions, and i don't have to
| actually think about any of the separation.
|
| Plus there's network shares. Multiple people in my home with
| linux PCs, each with their own slice of the NFS pie based on
| user perms. Sure, it's not secure, but these are people I live
| with, not state-sponsored hackers.
|
| All that said, I'd also love a simpler single-user perm setup.
| For VMs, containers, etc it would be amazing
| airocker wrote:
| NixOS at it again :)
| adastra22 wrote:
| I'm not sure how "I don't have to actually think about any of
| the separation" meshes with the fact that you explicitly
| setup multiple users and configured file and group
| permissions accordingly. You clearly put a lot of thought
| into it.
|
| Alternatively, containers really are a no-thinking-required
| solution. Everything maximally isolated by default.
| oceanplexian wrote:
| Containers are isolated but a far, far cry from maximally
| isolated. They're still sharing a Linux Kernel with some
| hand waving and cgroups. The network isolation and QoS side
| is half-baked even in the most mature implementations.
|
| HVM hypervisors were doing stronger, safer, better
| isolation than Docker was 10 years ago. They are certainly
| no-thinking required though which leads to the abysmal
| state of containerized security and performance we have
| currently.
| airocker wrote:
| There have been no big cves of container escapes for a
| while now. I guess it can be considered secure enough.
| tetris11 wrote:
| DietPi does exactly the same using Debian
| inhumantsar wrote:
| > i can have one baremetal server with a dozen+ services, all
| with their own users and permissions
|
| I've used nixos and I don't really see how nixos is special
| apart from the declarative config. The same can/should be
| done with any distro and any config manager.
|
| And unless you were running Podman in rootless mode, the same
| setup applies to containers too.
| TZubiri wrote:
| access management is usually delegated to other systems that
| supervise UNIX, like AWS
| airocker wrote:
| Or Kubernetes. Thats where a standard way of
| authentication/authorization should be there.
| gnufx wrote:
| Visit the research computing environment sometime, for
| instance. The libzma SSH compromise was considered very
| worrying, after all.
| richardwhiuk wrote:
| That didn't need multi-users.
| mbivert wrote:
| I've never understood the need for sudo(1) on single-user,
| physical machines: I keep a root shell (su(1)) around for admin
| tasks, and it's always been sufficient.
| airocker wrote:
| Its just maybe easier way to not have to go to the root
| shell.
| mbivert wrote:
| Makes sense (I keep one warm in a tmux, two shortcuts away
| at most, so it never occurred to me).
| lupusreal wrote:
| One password is easier than two and it feels weird to use the
| same password for both accounts. About half of my sudo
| invocations are 'sudo su' lmao.
| chgs wrote:
| Everything I run with sudo is logged so I know how I messed
| up.
|
| Nothing worse than ansible with its "sudo /tmp/whatever.sh"
| which hides what it's doing.
| anonymous_union wrote:
| in some other systems the concept has become overloaded.
| instead of multiple real people as users, different software
| with different permissions are different users. its not a bad
| abstraction.
| airocker wrote:
| Maybe containers are a better way of isolating processes as
| mentioned in other comments.
| berkes wrote:
| I always still split up "sysadmin" from "deploy".
|
| Ephemeral setups (amongst which k8s) remove that need but
| introduce a big load of other stuff.
|
| Having a VPS that is managed by sysadmins (users with sudo
| rights, authed with keys) and on which partly overlapping
| "deploy" users can write to small parts and maybe do a
| passwordless "sudo sysctl restart fooapp" but only that, is a
| nice and simple setup.
|
| I manage at least seven of these. And nothing in me even
| considers porting this to my k8s infra.
|
| Edit: The reason for this setup is simple and twofold: deploy
| is safe and clear: deployers can be confident that whatever
| crap they pull, the server will churn on, data will be safe,
| recovery is possible. And all devs/ops having their own keys
| and accts gives a trail, logs and makes it very easy to remove
| that contractor after she did her work.
| theteapot wrote:
| I think you mean systemctl.
| mbreese wrote:
| _> across unix multiuser environments getting used anymore for
| servers_
|
| I guess it depends on the servers. I'm in academic/research
| computing and single-user systems are the anomaly. Part of it
| is having access to beefier systems for smaller slices of time,
| but most of it is being able to share data and collaboration
| between users.
|
| If you're only used to cloud VMs that are setup for a single
| user or service, I guess your views would be different.
| shrimp_emoji wrote:
| > _If you 're only used to cloud VMs that are setup for a
| single user or service, I guess your views would be
| different._
|
| This is overwhelmingly the view for business and personal
| users. Settings like what you described are very rare
| nowadays.
|
| No corporate IT department is timesharing users on a
| mainframe. It's just baremetal laptops or VMs on Windows with
| networked mountpoints.
| mbreese wrote:
| Multi-user clusters are still quite common in HPC. And I
| think you're not going to see a switch away from multi-user
| systems anytime soon. Single user systems like laptops
| might be a good use-case, but even the laptop I'm using now
| has different accounts for me and my wife (and it's a Mac).
|
| When you have one OS that is used on devices from phones,
| to laptops, to servers, to HPC clusters, you're going to
| have this friction. Could Linux operate in a single-user
| mode? Of course. But does that really make sense for the
| other use-cases?
| airocker wrote:
| you could potentially create multiple containers in that
| machine which are single user and give to every user who
| needs access. CPU/Memory/GPU can be assigned in any way
| you want(shared/not shared). Now no user can mess up
| another user.
| NewJazz wrote:
| You only have one admin? How do you know who logged in, ssh
| certificates?
| trueismywork wrote:
| You'll just end up implementing multiuser support anyway due to
| different permissions to different devices services
| gnufx wrote:
| In fact, if factotum were implemented on Unix along with an
| analogue to the Plan 9 capability device, venerable programs like
| su and login would no longer need to be installed ''setuid
| root.'' -- https://plan9.io/sys/doc/auth.html
| broknbottle wrote:
| sudo machinectl shell "${username}"@
|
| sudo /usr/bin/systemd-run --machine="${username}"@ --quiet --user
| --collect --pipe --wait "${command}"
| Xeamek wrote:
| 2 weeks ago I didn't understood the systemd hate. But I tried to
| run udev-requiring program on non-systemd based distro.
|
| And now I don't like systemd anymore.
| suprjami wrote:
| So, you don't like a component because you ran software which
| requires that component, and you intentionally ran it in an
| environment without that component.
|
| That does not make sense to me?
| rezonant wrote:
| Well, _I_ tried to run a Mac binary on Windows and it didn 't
| work, so now I don't like Mac.
| vpzom wrote:
| The popularity of systemd encourages people to require it,
| which is the major problem
|
| that said iirc udev was formerly separate and active forks
| still exist
| JoshTriplett wrote:
| > The popularity of systemd encourages people to require
| it, which is the major problem
|
| The _usefulness_ of systemd encourages people to require
| it. People require it in cases where either there isn 't an
| alternative, the alternative isn't maintained, or the
| alternative is missing functionality.
| bhaney wrote:
| You must absolutely despise libc
| lmm wrote:
| libc has multiple independent implementations, if you don't
| like one you can switch to another. Software that hard-
| depends on a specific libc is indeed to be despised.
| deadbunny wrote:
| I tried filling up a Tesla at a gas station.
|
| And now I don't like electric cars anymore.
| lupusreal wrote:
| You joke but the inability of BEVs to make use of the gas
| station infrastructure is probably their number one obstacle
| to mass adoption.
| shrimp_emoji wrote:
| You just rent some parking space for the charge pylons.
| Probably off to the side where the self-service wash
| hose/tire pump usually is.
| mynameisnoone wrote:
| The blob continues its mission creep.
| ivanjermakov wrote:
| Offtop: long mastodon/X threads are so inconvenient that I would
| not even consider it a use case of such platforms. Write a blog
| post and link it there, ffs
___________________________________________________________________
(page generated 2024-04-30 23:00 UTC)