systemd Highlights For 2024 From Run0 To Varlink To Advancing systemd-homed

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67417

    systemd Highlights For 2024 From Run0 To Varlink To Advancing systemd-homed

    Phoronix: systemd Highlights For 2024 From Run0 To Varlink To Advancing systemd-homed

    Systemd had another busy year working on many new features from run0 as a sudo alternative to making systemd-homed more robust, increasing Varlink use, systemd-boot continuing to gain more traction, and more...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • mobadboy
    Senior Member
    • Jul 2024
    • 182

    #2
    Making sure the impressions are strong leading into next year. No flame, I'd do the same.

    Comment

    • rafanelli
      Phoronix Member
      • Apr 2022
      • 60

      #3
      Seem like we'll have linux-android (handheld), linux-systemd (server, desktop) and linux-alpine (containerized) and a marginal linux-other (sys-v, rcs, etc. -- for special use cases and the orthedoxy amongst us).

      Comment

      • Kjell
        Senior Member
        • Apr 2019
        • 706

        #4
        I really enjoyed this feature

        Systemd 256.1 Fixes "systemd-tmpfiles" Unexpectedly Deleting Your /home Directory

        Comment

        • ReaperX7
          Phoronix Member
          • Feb 2024
          • 68

          #5
          I like the bug fixes and all, but why do we need more features that exist already? Why not focus efforts to introduce new features not yet in GNU/Linux that could be useful?

          Comment

          • oiaohm
            Senior Member
            • Mar 2017
            • 8516

            #6
            Originally posted by ReaperX7 View Post
            I like the bug fixes and all, but why do we need more features that exist already? Why not focus efforts to introduce new features not yet in GNU/Linux that could be useful?
            Some did get in there this year.

            Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


            This one interesting as varlink does not use a central server.

            Remember lot of the redo of existing features is because there is some limitation. Like using varlink instead of dbus means you are not dead in the water. When I said dead in the water what happens if dbus service does not start. Varlinks lack of central server means using it is not adding another single point of absolute failure.

            Comment

            • anda_skoa
              Senior Member
              • Nov 2013
              • 1223

              #7
              Originally posted by ReaperX7 View Post
              I like the bug fixes and all, but why do we need more features that exist already? Why not focus efforts to introduce new features not yet in GNU/Linux that could be useful?
              A new implementation of a feature can have many advantages.
              It could be faster, safer or use less resources.

              It could make the code more maintainable and/or more extendable and thus easier to implement the new feature you were hoping for.

              Comment

              • polarathene
                Senior Member
                • Nov 2014
                • 1336

                #8
                Originally posted by rafanelli View Post
                Seem like we'll have linux-android (handheld), linux-systemd (server, desktop) and linux-alpine (containerized) and a marginal linux-other (sys-v, rcs, etc. -- for special use cases and the orthedoxy amongst us).
                Alpine for containers due to what reasons? There's various caveats in choosing alpine as a base image, some you can work around when you're aware of them.

                If you wanted size, depending on the final output both Fedora and OpenSUSE can be reasonably competitive with dnf and zypper using their install root options to install to a rootfs location that you copy to a scratch image, no package manager or any other packages not needed. They're not perfect though as the package deps aren't as granular for containers to minimise size but you can have images that are like 10MB without the alpine caveats.

                There's also Google's distroless (debian) images or for more flexibility canonical's chisel. Both can do base images that are like 1-2MB in size.

                Comment

                • ReaperX7
                  Phoronix Member
                  • Feb 2024
                  • 68

                  #9
                  Originally posted by anda_skoa View Post

                  A new implementation of a feature can have many advantages.
                  It could be faster, safer or use less resources.

                  It could make the code more maintainable and/or more extendable and thus easier to implement the new feature you were hoping for.
                  Sudo is maintained and is literally a UNIX standard for user access control. It doesn't need to be replaced. My opinion, but this is adding nothing of value accept to bloat the software even more with a duplicate feature native to Linux only out of spite to BSD and other non-Linux solutions.

                  To me, this is could we? Yes. Should we? No!

                  Comment

                  • oiaohm
                    Senior Member
                    • Mar 2017
                    • 8516

                    #10
                    Originally posted by ReaperX7 View Post
                    Sudo is maintained and is literally a UNIX standard for user access control. It doesn't need to be replaced. My opinion, but this is adding nothing of value accept to bloat the software even more with a duplicate feature native to Linux only out of spite to BSD and other non-Linux solutions.

                    To me, this is could we? Yes. Should we? No!
                    Funny enough doas comes from Openbsd and this is the sysvinit maintainers work to bring doas to Linux. Solaris 10(year2005) and before has pfexec with no sudo.

                    ReaperX one reality is sudo is not Unix standard or POSIX standard
                    https://en.wikipedia.org/wiki/List_of_POSIX_commands Notice no sudo on this page and you can look up the Posix documents and see no Sudo.
                    Yes sudo is not a command you are required to have to be a "Single UNIX Specification" certified OS that you are required to have so you can use the Unix trademark on your OS.

                    ReaperX there are lots of commands people say are Unix Standard that are in fact not Unix Standard. Sudo and su like it or not optional add on to a Unix OS. This is why doing lots of things across Unix/Linux/BSD OS get tricky very quickly things are not as uniform as people think or try to make out.

                    Run0 is in fact different to sudo and su.

                    run0 may be used to temporarily and interactively acquire elevated or different privileges. It serves a similar purpose as sudo(8), but operates differently in a couple of key areas:
                    • No execution or security context credentials are inherited from the caller into the invoked commands, as they are invoked from a fresh, isolated service forked off by the service manager.
                    • Authentication takes place via polkit, thus isolating the authentication prompt from the terminal (if possible).
                    • An independent pseudo-tty is allocated for the invoked command, detaching its lifecycle and isolating it for security.
                    • No SetUID/SetGID file access bit functionality is used for the implementation.
                    Altogether this should provide a safer and more robust alternative to the sudo mechanism, in particular in OS environments where SetUID/SetGID support is not available (for example by setting the NoNewPrivileges= variable in systemd-system.conf(5)).

                    Any session invoked via run0 will run through the "systemd-run0" PAM stack.

                    Note that run0 is implemented as an alternative multi-call invocation of systemd-run(1).
                    Yes reading the man page helps here.
                    There are a few ways to break sudo so it cannot function.

                    1) Yes you have NoNewPrivileges=true set with systemd then SetUID/SetGID don't work resulting in sudo being non functional because it requires SetUID/SetGID.
                    2) you mount root file system with -o nosuid this again kills SetUID/SetGID making sudo non functional
                    3) You set Linux Security Module like SELinux to block SetUID/SetGID this again blocks SetUID/SetGID so making sudo non functional.

                    run0 works in all 3 of the above cases without problems.

                    [EINVAL] The value of the uid argument is invalid and not supported by the implementation.​
                    So its perfectly valid by Posix/Unix Standards to have non functional SetUID and SetGID so Linux is doing nothing wrong as Posix/Unix OS having options that equal SetUID/SetGID non functional. So sudo not working is Posix/Unix Standard conforming.

                    Yes a sudo that functions more like run0 would be more Posix/Unix Standard compatible than current sudo offerings. File socket functionality that varlink run0 uses is more ensured to exist by posix/unix standard than SetUID/SetGID.

                    Comment

                    Working...
                    X