Announcement

Collapse
No announcement yet.

How To Use Systemd For Application Sandboxing & How To Easily Crash Systemd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by GreekGeek View Post
    Hi yall,

    Re-posting, because of what might politely be called, "strident pro-systemd" peeps...

    Over this past year, I've seen a lot of frequently-used but logically invalid arguments for using systemd.  This blog post is meant to serve...


    GreekGeek :-)
    That blog another load of cock

    Comment


    • #22
      Originally posted by curaga View Post
      ...this is exactly the kind of thing I, and a few million others, foresaw when systemd first appeared. Ahem. Trying hard to suppress a told-you-so.
      yawn....... do you do the same for bugs are found in the kernel, openssl, x-org etc? its not a few million others, its just a few empty vessels making a load of noise (as empty vessels do)

      Comment


      • #23
        Why systemd? There are some standalone programs for sandboxing too. One of them is selfdock, that I'm making.

        Using it in production on my home server now.

        Comment


        • #24
          Originally posted by GreekGeek View Post
          Hi yall,

          Re-posting, because of what might politely be called, "strident pro-systemd" peeps...



          GreekGeek :-)
          Disassembling this bullshit for fun ang giggles.

          >>Fallacy #1: "Systemd is multiple binaries, therefore it is not monolithic"

          I'd like to know how the author of that blog defines microkernels, as by standard and accepted definition they are not "monolithic" as they run drivers and stuff in userspace (while monolithic kernels are called as such because they keep both kernel and drivers and stuff in kernel space), but according to his definition (they are not composed of independent parts) they should be monolithic too.

          Our lord and saviour Pottering is using the correct definition of "monolithic", that is a mirror of the linux kernel's.
          If Systemd had to keep all its stuff in PID1 it is monolithic (just as linux kernel that keeps all modules in kernelspace), if it does use PID1 only for some crucial things that actually need it then it is not.
          Systemd happens to NOT keep all its daemons in PID1 for lulz, so no, it's not monolithic.

          >>Fallacy #1.1: "Systemd's components have well-defined interfaces, so you can just replace the parts you don't like."

          Which is true for most things you might want to replace or split and keep separate (there are like 3-4 independent logind for example).
          For the core components or those in development it's an unrealistic request, besides if you feel you can make something at core-level in systemd, you should be able to mantain your own fork of it.
          I'm not getting why that is wrong. You can't make modifications to core components in any software project without needing to devote significant amount of time to rebasing and mainteneance anyway.

          >>Fallacy #1.2: "The Linux kernel is monolithic, therefore it is okay for systemd to be monolithic"

          The writer's own fantasy is speaking here. Pottering said it is not, by non-stupid definitions it is not. So why should it become monolithic and it should also become ok as linux kernel is?

          >>Fallacy #2: "Lots of people use systemd, therefore you should too"

          More like "if all distros apart from a couple niche ones ship systemd by default there must be good reasons" As the decisions to include or not systemd isn't made by dumb cows... errr I mean users, but by mantainers that tend to know what they are doing.

          >>Fallacy #2.1: "Systemd earned widespread adoption through its technical merits"

          this happens to be true, to the contrary of what the butthurt author tries to claim.
          systemd adoption by the distro mantainers happened because of its technical merits.

          >>Why do distributions adopt systemd, if not for its technical merits? A big motivating factor is that other application suites (e.g. GNOME) increasingly depend on it to work. If the goal of the distribution is to provide support for these end-user application suites, then pulling in systemd as a dependency is only a means to that end: they're not adopting systemd because it's technically superior; they're adopting it because it's less costly than maintaining patches to keep systemd decoupled.

          And why other application suites depend on systemd? because of its technical merits.

          >>Speaking of adoption, how does one measure "widespread?" Android is probably the most widely-used Linux-powered OS by far, and it doesn't use systemd. Perhaps the most widely-deployed consumer GNU/Linux distribution by sales is ChromeOS, but ChromeOS uses Upstart, and that probably won't change. So, arguably systemd isn't that widespread across the Linux landscape in the first place.

          So, we pull in Android, the embedded thing with a java userspace as a "linux-powered OS", which means jackshit. Might as well pull in all consumer routers, NAS and other assorted embedded devices too.

          Also, ChromeOS, the weird-ass web-kiosk OS as a "widely deployed consumer GNU/Linux distribution". Yeah right.

          Ah but it was to claim that systemd isn't widespread. It makes sense.

          >> Also, have a look at Debian's popcon numbers for systemd-sysv vs sysvinit-core. At the time of this writing there are roughly 3x as many installs as systemd-sysv (which conflicts with sysvinit-core)

          even more bullshit, these numbers are taken from Debian, whose usebase is on the Stable (i.e. outdated) release, and they aren't terribly accurate in the first place anyway.

          >>Fallacy #3: "People who don't like systemd just don't like change"

          This is actually true until the no-systemd crowd can produce some good valid reasons why systemd is bad, and not random bullshit wordplay nonsense or "i can't read the manual" or whatever.

          >>It assumes that the user is comfortable adding all of systemd's code to his/her trusted computing base.

          The overwhelming majority of users offload that decision to distro mantainers for everything already, so it's nonsense.

          >>It assumes that the user isn't already doing advanced things with namespaces and cgroups which systemd would break.

          Even assuming someone was using namespaces and cgroups so extensively before (I'd say not many), why should systemd break that?

          >>It assumes that the user is unhappy with his/her current service management setup, which systemd would replace.

          The overwhelming majority of users offload that decision to distro mantainers for everything already, so it's nonsense.

          >>It assumes that the user has sufficient RAM, CPU, storage, and power to add systemd to his/her running computer. This is not always the case for low-power embedded Linux, where "init" might just be the embedded application itself (NB: I'm referring to really low-powered devices such as this, not smartphones or equivalent hardware).

          A depressingly weak argument, as we don't run desktop or server distros in embedded hardware anyway. Also, the example is a depressingly weak system even for embedded, good only for IoT embedded usage.

          hell, even OpenWRT/LEDE would barely fit in 4MB of flash and can't run with 8MB of ram.

          Btw, most modern embedded devices tend to come with wider flash storage and RAM now as the price of flash/RAM chips depends from the demand (more demand = more production runs = lower price) and not directly from the capacity.

          >>It assumes that the user has a sufficiently recent Linux kernel. This is also not always the case with more exotic hardware, where proprietary kernel modules can keep you locked into an old version.

          Again a depressingly weak argument, crap hardware with blobs is crap hardware with blobs, systemd is just one among the other issues they already have.

          >>It assumes that the user will have a completely bug-free experience and will not have to sink unjustifiable amounts of time into setting systemd up in their environment.

          Which, in cases where the user is using a distro or knows how to read the manual, is true.
          And in cases where the user is starting from scratch, it's even better than sysvinit where you need to write tons of boilerplate in scripts.

          >>It assumes that the user will easily be able to migrate away from systemd if it turns out to be a bad match down the road.

          No it does not. Systemd does not assume that people will migrate easily away from it the same as sysvinit, or linux kernel or whatever the fuck else do not.

          >>A provably-correct init system would be ideal, but a tried-and-true well-understood init system would be preferable to an unproven one.

          which is why everyone in the field hates scripts, because while with systemd you can just call tried and tested routines that also everyone else is using, with custom scripts everything is new and tested only on your system.

          Really, old sysvinit is tried and tested but the old sysvinit isn't doing jackshit without scripts.

          >>Dismissing other peoples' init system requirements as illegitimate is a great way to get written off as a troll. So is trying to tell them they're wrong about their own requirements.

          LolwtfWAT?

          Who the hell dismissed anyone?

          >>Fallacy #4: "Unit files are better than shell scripts"

          true. Just fucking true for anyone that had to work with custom initscripts.

          >>Fallacy #4.1: "Unit files reduce complexity"

          Yes dumbass, moving the complexity all into ONE place which is tested and used by all is the entire point, and the reason why it's better than dozens of distro-specific scripts to do the same thing or even custom ones that are tested by much less people.
          By using a unit in my custom service I'm using parts that are as tried and tested as they can possibly be, while a custom script is tested by none other than myself.

          >>Fallacy #4.2: "Shell scripts are buggy"

          same as above. Also, shell scripts are buggy because they have plenty of undefined behaviours that might work until it doesn't, which isn't there with systemd.

          >>In practice, if the shell script fails to execute, the bug is almost always in the script, not the underlying shell or program it invokes.

          yeah right. let's handwave away the fact that shells have plenty of undefined behaviour that is specific or weird or legacy or whatever and tricks the user into doing something that might be wrong in some cases.

          >> If systemd fails to act on a valid parameter of a unit file, however, the user must debug systemd's C code to find out why.

          true but that kind of obvious mistake is pretty hard to get through the automated testing systemd undergoes, while who is auto-testing my scripts? Anyone?

          >>Fallacy #4.3: "Systemd is better because it gets rid of shell scripts!"

          this is the same stuff as said in point 4.

          >>However, shell scripts were never necessary to boot your system in the first place.

          And who goddamn cares of booting if you cannot control what is going on afterwards? Are we all running mono-application embedded systems here?

          >>Fallacy #4.4: "Systemd is better because it reduces shell script code duplication!"

          That's one of my points, and yes, try to ask yourself why none has yet made a "big initscript repository" for all to consolidate scripts.

          >>Fallacy #5: "Systemd enables you to use $LINUX_SPECIFIC_FEATURE"

          The features are there but most people are more confortable with configuration files, not with programming.
          Nice bullshit argument tho.

          >>Fallacy #6: "Systemd is open source, so if you don't like it, you can fork it!"
          >>Fallacy #6.1: "Those systemd detractors should stop whining and make their own alternative!"
          >> Most non-systemd users are perfectly happy to leave systemd alone and let it do its thing for the people who want to use it. Whatever init system they are currently using is perfectly fine for their needs.

          Yeah, luddites always existed, point is, the rest of the world isn't supposed to help them keep their delusions, so they need to keep supported the stuff they are using currently on their own.
          Which in this case means forking or making shims.

          >>The problem is that the systemd project doesn't want to leave them alone.

          see above.

          >>A lot of non-systemd users don't need a systemd clone, since they're happy with what they have already. So, there's no point in telling them to go work on cloning systemd.

          They need to make a shim to run in a crappy and unsafe and stupid way the stuff that is supposed to work with systemd's project stuff, as most program developers don't need to care about the needs of a minority of luddites.

          >>Fallacy #7: "You should use systemd, since it gives you socket activation!"

          probably the same case of above, systemd provides an easy handle for stuff offered by kernel.

          >>For Internet socket activation, all the user has to do is start the daemon, have it bind on the port, and let it sit there idly. If the kernel needs RAM, it will swap the (idle) daemon to disk. If the kernel receives an incoming connection, it will swap the daemon back into RAM so it can handle it. Systemd isn't involved at all here, but it has the same effect. As an added bonus, the kernel's virtual memory subsystem ensures the daemon's runtime state gets preserved across swaps--something systemd does not allow with its form of socket activation.

          Ummmm.... this is "starting stuff, binding to port then relying on swap", while systemd socket activation is "systemd listens on port and if connection arrives starts the daemon, then if not needed anymore it shuts down the daemon".

          This is most useful for devices with limited resources, or without a buttload of swap.

          >>Fallacy #7.1: "You should use systemd, since it lets you assign targets to be activated on receiving the connection!"
          >>Fallacy #7.2: "You should use systemd, since it supports more than network sockets! It supports pipes and UNIX sockets too!"

          I think this was more like "systemd lets you consolidate a dozen of stuff into a single one!" than "only systemd can do it" which is obvious bullshit.

          >>Fallacy #7.3: "You need to use systemd for socket activation, since otherwise you'll encounter race conditions with parallel start-up!"
          >>Ideally, B is smart enough to do this on its own. If not, the socket activation solution proposed by systemd is to modify processes A[0]...A[n] so that they receive a socket descriptor from systemd, which systemd used to buffer up messages from B while each A[i] was starting up (systemd's "socket activation"). This lets B start in parallel with A[0]...A[n] while preventing it from making forward progress until A[0]...A[n] are all listening.

          wat? systemd buffers stuff without modifying programs. And no, most programs aren't smart enough to deal with the fact that they don't get any answer from their pals on their own.

          >>Fallacy #8: "$PROGRAM doesn't depend on systemd, it just depends on something that implements systemd's interface"

          Then make a shim for this "something that implements systemd interface" duh. There are logind shims for example.

          >>Fallacy #9: "Systemd is the KISS principle in action"

          At point 4.1 you claimed bullshit that missed the point completely, systemd reduces useless complexity by a ton and allows you to do very complex things using very well-tested components.
          Scripts can't do that.

          >>Fallacy #10: "Binary log files aren't a problem in practice"

          what was in this paragraph is the usual bullshit, ignoring foremost that binary logging isn't even mandatory.

          >>Fallacy #10.1: "Journald's binary format lets its perform authenticity and integrity checks"

          not stated anywhere.

          >>Fallacy #10.2: "Journald binary format lets it have an index that makes log access faster"

          I'm not seeing the point of making a split index, placing the index inside the text file is retarded as fuck, and you can simply set the whole thing to output to the usual logging system and skip this.

          >>Fallacy #10.3: "All the problems you have with journald can be avoided by having it simply pass everything to syslog"
          >> This assumes a faulty premise that there is a need for journald at all in this case. If all the user needs is syslog, then why require journald at all?

          Because jorunald is the only one that can log stuff happening on early boot, so during early boot yes it is running. Afterwards it dumps all the logs on syslog.

          >>Fallacy #11: "People who don't like systemd really just don't like Lennart Poettering, and that's not a valid excuse to avoid it"

          For most systemd-haters this is actually true, as they see Pottering as some kind of Antichrist that wants to take over Linux and kill the Unix way and whatever.

          And as someone that dismisses bullshit as bullshit, and as someone that exposes dumb implementations or things that were also broken before but were mostly hidden by crappy sysv before.

          >>Fallacy #11.1: "You should judge systemd on its technical merits alone, otherwise your criticisms are wrong"
          >>To judge on technical merits alone, there first needs to be a formal specification that precisely and unambiguously defines what systemd does and does not do. Second, there needs to be a formal proof that systemd's implementation meets this specification. Both are necessary to evaluate systemd on its technical merits alone; otherwise, there's no way conclusively show that systemd meets the requirements.

          wat? Is the documentation and the full source not enough to be sure of what the program does? Is this guy on drugs?

          >>Fallacy #13: "Systemd has at least 574 contributors from many different backgrounds, therefore it is not pushed or controlled by a small group"

          Even if it was pushed or controlled by a small group (RedHat), I'm still not seeing the issue. Many other projects are also controlled by a small group, and it's not an issue.

          Comment


          • #25
            Originally posted by Rubble Monkey View Post

            I like that he gave the whole blog a good look, but what I didn't like (which for some reason applies to most systemd defenders) is that he calls "missing the bigger picture" "throwing a tantrum". He even admits that valid points were brought up (which is admirable to do for something he supports that much) but he still tries to make the author look childish and discredit him instead of just correcting him!
            because 1) author is idiot 2) his pointers valid for any competition 3) he proposed to throw away whole systemd instead of fixing few pointers
            btw, you are idiot too

            Comment


            • #26
              Originally posted by GreekGeek View Post
              Hi yall,

              Re-posting, because
              you are idiot and didn't understand anything after previous reposts of this bullshit

              Comment


              • #27
                Originally posted by pal666 View Post
                because 1) author is idiot 2) his pointers valid for any competition 3) he proposed to throw away whole systemd instead of fixing few pointers
                btw, you are idiot too
                And the funny thing about #3 is that if that where how all software where developed there would be no version of anything in use since every project trips on one bug in it's lifetime. For example if one bug your out had been the standard back in the day then there would never have been a SysV Init to begin with.

                Comment


                • #28
                  Originally posted by starshipeleven View Post
                  >>It assumes that the user has sufficient RAM, CPU, storage, and power to add systemd to his/her running computer. This is not always the case for low-power embedded Linux, where "init" might just be the embedded application itself (NB: I'm referring to really low-powered devices such as this, not smartphones or equivalent hardware).

                  A depressingly weak argument, as we don't run desktop or server distros in embedded hardware anyway. Also, the example is a depressingly weak system even for embedded, good only for IoT embedded usage.

                  hell, even OpenWRT/LEDE would barely fit in 4MB of flash and can't run with 8MB of ram.

                  Btw, most modern embedded devices tend to come with wider flash storage and RAM now as the price of flash/RAM chips depends from the demand (more demand = more production runs = lower price) and not directly from the capacity.
                  I had the impression that systemd is supposed to be used everywhere. From Raspberry Pi style hardware to computer centers. They don't clearly state that they don't want to support low end hardware. The only fact you can infer is that they like glibc and glibc/gnu extensions which make systemd compatible with minimal/standard compliant C libraries like musl. So apparently instead they hate POSIX and low end hardware.

                  About the hardware.. there are plenty of router boxes which come with 4-16 MB of flash and even support 802.11ac. They will be here for a long while. Now, systemd expects glibc and refuses to work with other libc implementations so the router would probably need at least 128 MB, maybe 1-8 GB of flash to work with systemd mainly due to the larger footprint of glibc (compared to 8-16 which is sufficient now). Or maybe they should ship glibc for systemd and the smaller libc for everything else?

                  OpenWRT is actually moving to musl and systemd isn't compatible with musl since they expect some GCC/GNU extensions and not POSIX libc. Either 1) OpenWRT becomes irrelevant as hardware keeps improving 2) OpenWRT moves to a stripped down version of systemd with minimal services and switches back to glibc 3) 2 + OpenWRT patches musl with GNU extensions to make it work with systemd 4) 2 + systemd / musl folks fix their stuff 5) OpenWRT adopts two libc libraries, one for systemd and the other for all other software.

                  Finally, even if OpenWRT adopts systemd, the user won't gain any significant improvements. Maybe if he/she plans to run containers and hotplug stuff, but otherwise it's all just bloat with no improved functionality.

                  The most popular hacker friendly IoT devices are Arduino and ESP8266 chips which won't even run Linux. Commercial vendors might even use lower spec machines with RTOS or bare metal OS. It doesn't really make any sense to use Linux since these devices are expected to harvest energy from solar, wind, temp changes, pressure, radio waves etc. Idle power of 5-10 mW might be too high. Now that chip production is close to atomic level, I have my doubts that Linux will ever get there. Perhaps, if we are lucky. So the majority of embedded / IoT devices definitely won't ever ship with enough storage for Linux and systemd. Why would anyone want a 'smart button' (like the Amazon one) with a full blown OS?

                  Comment


                  • #29
                    Hi yall,

                    @ pal666, starshipeleven & rtfazeberdee, please see ad hominem fallacy....

                    FYI: Ad hominem (Latin for "to the man" or "to the person"), short for argumentum ad hominem, is a logical fallacy in which an argument is rebutted by attacking the character, motive, or other attribute of the person making the argument, or persons associated with the argument, rather than attacking the substance of the argument itself. ( https://en.wikipedia.org/wiki/Ad_hominem )

                    GreekGeek :-)

                    Comment


                    • #30
                      Originally posted by Serafean View Post

                      Owncloud.
                      You would just need write access for the php-fpm processes then. I would also suggest having the web root mounted as noexec, however there is always a risk that owncloud will place for example php files where it shouldn't.

                      Comment

                      Working...
                      X