Stories
Slash Boxes
Comments

SoylentNews is people

posted by mrpg on Wednesday May 30 2018, @12:10AM   Printer-friendly
from the one-process-to-rule-them-all dept.

Systemd Introduces "Portable Services" Functionality, Similar To Containers

Lennart is at it again, making complicated things that nobody asked for.

The past several months Lennart Poettering has been working on a "portable services" concept and that big ticket new feature has now landed in Systemd. Portable services are akin to containers but different.

[...] A portable service is ultimately just an OS tree, either inside of a directory tree, or inside a raw disk image containing a Linux file system. This tree is called the "image". It can be "attached" or "detached" from the system. When "attached" specific systemd units from the image are made available on the host system, then behaving pretty much exactly like locally installed system services. When "detached" these units are removed again from the host, leaving no artifacts around (except maybe messages they might have logged).

[...] The primary focus use-case of "portable services" is to extend the host system with encapsulated extensions, but provide almost full integration with the rest of the system, though possibly restricted by effective security knobs. This focus includes system extensions otherwise sometimes called "super-privileged containers".


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Flamebait) by darkfeline on Wednesday May 30 2018, @05:59PM (5 children)

    by darkfeline (1030) on Wednesday May 30 2018, @05:59PM (#686381) Homepage

    I'm sure you can provide a reproducible example of such an issue, since you're not all just talk. Ignoring the fact that the logs are signed, not encrypted, the fact that the logs are just plain text with metadata and not full on binaries like uninformed haters proclaim, and the fact that the raw logs can be extracted without the metadata with the standard strings commands, and the fact that it's trivial to flood syslog and wipe out traces of suspicious activity (you don't even have to be root!), and... Actually, that's too many facts for SN, sorry.

    --
    Join the SDF Public Access UNIX System today!
    Starting Score:    1  point
    Moderation   -1  
       Flamebait=1, Total=1
    Extra 'Flamebait' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   1  
  • (Score: 4, Informative) by Arik on Wednesday May 30 2018, @08:20PM (4 children)

    by Arik (4543) on Wednesday May 30 2018, @08:20PM (#686456) Journal

    Where have you been the last few years?

    Hit the search engine(s) of your choice and look for systemd log corruption. This sort of problem has been reported repeatedly for years, discussed on this very site several times.

    https://www.freedesktop.org/wiki/Software/systemd/journal-files/ [freedesktop.org]

    That's sort-of the official documentation for the thing. We'll come back to the sort of in a moment, but notice THE VERY FIRST PARAGRAPH here.

    Note that this document describes the binary on-disk format of journals only. For interfacing with web technologies there's the Journal JSON Format. For transfer of journal data across the network there's the Journal Export Format.

    (Emphasis in the original.)

    Ok, on to how this only sort-of the official documentation. Still right at the top of the document.

    Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right.

    Yeah, no, I didn't make that up, just hit the link. They claim codebase infallibility. It is impossible, by definition, for Poettering to make an error when he is in the coders chair. He can't violate the spec, because as soon as he hits commit his words ARE the spec!

    Anyway don't believe me, search for it, as I say many people have reported corruption problems and been told there is no way to recover. The workaround is to simultaneously export to plain text, just in case, but even once configured that workaround seems to have serious issues as well. This has been an ongoing issue for years and if you spend a little time looking you'll find some astonishing responses.

    --
    If laughter is the best medicine, who are the best doctors?
    • (Score: 1, Flamebait) by darkfeline on Thursday May 31 2018, @05:49PM (3 children)

      by darkfeline (1030) on Thursday May 31 2018, @05:49PM (#686846) Homepage

      So what? All you're telling me is that journal corruption happens (I never claimed that it didn't; if filesystem corruption can happen, which it can, then by definition journal corruption can happen), and that the authoritative description of the format is in the code. This addresses roughly zero of the points that I brought up. Well done.

      Also, anecdotal evidence isn't very valuable, Here's another data point: I have never experienced systemd journal corruption, and many others also have not. If you can reliably induce it, by all means enlighten us.

      --
      Join the SDF Public Access UNIX System today!
      • (Score: 3, Informative) by Arik on Friday June 01 2018, @01:16AM (2 children)

        by Arik (4543) on Friday June 01 2018, @01:16AM (#687012) Journal
        What you're missing is the consequences.

        When you have a normal case of log corruption, you can typically recover 90%+ of the data. It doesn't require any special tools, and a clever teenager can figure it out with no help (I know because back when I was one I did.)

        When you have a corrupted binary file in a format which doesn't even have truly authoritative documentation outside of the source code, it's a very, very different situation. Recovering those files is still theoretically possible, of course, but it could not be done on any reasonable timescale without special tools. Tools which don't exist, and which will very likely never exist. The systemd authors refuse to even admit there's a problem, and who else is going to try to write a low-level utility for a format that doesn't even allow proper documentation and will probably change with every release?

        It sounds like you've ignored my repeated pleas to take a few minutes and search this for yourself. As I said, there have been some quite startling replies to people who *have* experienced the issue.

        And reliably inducing? C'mon, you've got root on a box and you can't figure out a way to corrupt the bit of the log that you're going to be in? Really?

        --
        If laughter is the best medicine, who are the best doctors?
        • (Score: 1, Troll) by darkfeline on Friday June 01 2018, @10:15PM (1 child)

          by darkfeline (1030) on Friday June 01 2018, @10:15PM (#687473) Homepage

          When you have a corrupted binary file in a format which doesn't even have truly authoritative documentation outside of the source code, it's a very, very different situation. Recovering those files is still theoretically possible, of course, but it could not be done on any reasonable timescale without special tools.

          Special tools like the POSIX standard strings and grep commands, and reasonable timescales like half a second? You failed to read my original post which specifically addressed this point and made yourself look like the ignorant systemd hater strawman that I described. I mentioned explicitly that the log files are mostly text with some binary metadata.

          It sounds like you've ignored my repeated pleas to take a few minutes and search this for yourself.

          Yes, there are a lot of anecdotal cases, just like there are a lot of anecdotal cases of people corrupting perfectly stable file systems. It's hard to distinguish PEBCAK from actual bugs in these cases. The standard way of doing so is demonstrating the issue reproducibly.

          And reliably inducing? C'mon, you've got root on a box and you can't figure out a way to corrupt the bit of the log that you're going to be in? Really?

          So you're saying that having root lets you destroy the logs? Is that supposed to be a criticism of systemd? Here's what a real criticism looks like: syslog allows any user, or anyone on the same network if using the networked UDP protocol, to destroy logs emitted by system services.

          --
          Join the SDF Public Access UNIX System today!
          • (Score: 3, Informative) by Arik on Friday June 01 2018, @10:35PM

            by Arik (4543) on Friday June 01 2018, @10:35PM (#687489) Journal
            "You failed to read my original post which specifically addressed this point"

            No, you failed to read my rebuttal which destroyed your spurious point.

            https://www.freedesktop.org/wiki/Software/systemd/journal-files/ [freedesktop.org]

            "Note that this document describes the binary on-disk format of journals only. "

            You're talking about JEF. I mentioned that as well.

            I'm getting tired of trying to carry on a conversation with someone that for whatever reason doesn't bother to read my points and just keeps repeating misinformation.

            --
            If laughter is the best medicine, who are the best doctors?