| ▲ | greatgib 13 hours ago |
| Systemd, as usual randomly and suddenly breaking things that worked for decade and for people that asked nothing.
Because they know better what you need... |
|
| ▲ | nickysielicki 13 hours ago | parent | next [-] |
| And what's your preferred alternative to what's described in the article? Packaging every single service in its own 500mb ubuntu chroot and using docker? Running a local dhcp server and a bridge interface so that you can selectively expose ports? Here's an alternative title for this post: these days, two lines in a systemd service file can easily constrain arbitrary applications to just the files and resources they need, and only those. |
| |
| ▲ | probably_wrong 13 hours ago | parent | next [-] | | My grumpy preferred alternative would be "you're supposed to be an init service. That's not your job". | | |
| ▲ | Un1corn 12 hours ago | parent | next [-] | | > systemd is a suite of basic building blocks for a Linux system. You can always use a simpler init system if you want | |
| ▲ | nickysielicki 12 hours ago | parent | prev [-] | | I linked it elsewhere in this thread, but you should really watch this talk, particularly 12:45 through 16:20: https://www.youtube.com/watch?v=o_AIw9bGogo tl;dr: systemd isn't meant to be an init system, it's meant to manage services, and the alternative world where you don't have a unified system for managing services and events actually sucks. |
| |
| ▲ | silverquiet 12 hours ago | parent | prev | next [-] | | Doesn't SELinux do that (and more)? | | |
| ▲ | zokier 7 hours ago | parent | next [-] | | selinux doesn't really provide anything like ProtectHome or PrivateTmp mentioned in the article. SELinux only does access control, while systemd can create new resources that are scoped to specific service. | |
| ▲ | amluto 12 hours ago | parent | prev [-] | | The problem is the “more”. SELinux is extremely flexible and does what the configuration tells it to do. And it does not compose well. Want to point whateverd at /var/lib/whatever? Probably works if the distro packages are correct. Want to make /var/lib/whatever be a symlink? Probably does not do what you expect. Want to run a different daemon that accesses /var/lib/whatever or mount it into a container? Good luck. Want to run a second copy of the distro’s whateverd and point it at a different directory? The result depends on how the policy works. And worst: want to understand what the actual security properties of your policy are? The answer is buried very, very deep. |
| |
| ▲ | stefantalpalaru 12 hours ago | parent | prev [-] | | [dead] |
|
|
| ▲ | 12 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | wolrah 12 hours ago | parent | prev | next [-] |
| The example given is a distro changing their bundled systemd unit files to use new features, yet you choose to blame systemd? You do realize distros can also change SysV shell scripts in ways that break your use case as well, right? |
|
| ▲ | flanked-evergl 7 hours ago | parent | prev | next [-] |
| Systemd is probably the part of my distro that works best. |
|
| ▲ | oncallthrow 12 hours ago | parent | prev [-] |
| Did you read the article? The author is complaining that aystemd introduced _optional_ security mechanisms for units. If you don’t like these mechanisms, don’t use them in your units. Systemd didn’t “break” anything at all here. This author’s arcane debugging workflow doesn’t work for certain units who have opted into the new security mechanisms. But that is hardly systemd’s fault. |
| |
