On Wed, 24.08.11 00:24, Björn Persson (bjorn@rombobjörn.se) wrote: > Mathieu Bridon wrote: > > Well, socket activation gives you better speed and resource usage as > > already mentioned, but it also gives you: > > > [some really nifty features] > > > > So basically, much improved service availability (which is what matters > > to your business, isn't it?), and easier configuration/maintenance > > (granted, once you've learnt the new commands/tricks). > > > > Knowing that the security issue is highly exaggerated (as Lennart has > > repeatedly stated, systemd doesn't read network packets), does that seem > > like a better trade-off? > > It might be an acceptable trade-off but I'm not yet convinced that such a > trade-off is necessary. Is it really impossible to have both a simple, network- > unaware Init and all the nifty features of SystemD? > > Imagine a stripped-down Init that does only two things: First it forks and > executes SystemD, and then it just sits around and reaps orphan zombies. > SystemD would then run as process 2 and do all its socket activation and other > magic from there. Process 1 would then be immune to network-based attacks, and > it would be possible to kill SystemD if desired (although it would surely > leave the system rather handicapped). > > The only thing I can think of that would be a problem is if SystemD needs to > be notified when processes die even when those processes aren't children of > SystemD. Is that the case? Is there anything else that only process 1 can do? systemd is actually nicely stripped down. I am not sure what people think that is so bloated in PID 1? Is this hate for D-Bus, what is it? I am pretty sure systemd will win any competition in size and resource usage when you compare a systemd system with one built of a number of similar components, which offer the same functionality. And why is that so? Since it's lean C, and since it reuses common code as much as possible. If you have your bazaar of basic building blocks like we used to have it on Linux then the simple fact is that a big chunk of that code is just the same stuff implemented over and over again. You have the daemonization stuff, you have the process supervision, you have local IPC systems, for each and every component reimplemented again and again. And all these reimplementations have in common that they suck and are limited, and do not even remotely compare to the feature set that systemd offers you in trivially easy to use settings. (I mean, come on, PrivateNetwork=yes, you must love that, can't you guys admit that?) You know, there's a reason why systemd is popular for all kinds of embedded setups, why it is being used in mobile devices, on MeeGo, in cars, in children's toys, in household machines and all the other stuff: because it minimizes the stuff you need to build a system and reduces duplication, and guarantees robustness that was previously not available. I mean, seriously, we can run syslog now in a way that it can crash and can be restarted without losing a single packet, and all that fully in parallel getting rid of all dependencies and stuff. How awesome is that? Can you really see no benefit in all of this? I really honestly wished the troupe of you four or five people who keep trying to noisily shoot systemd down on fedora-devel would actually try to understand what is going on. Try to get the bigger picture. Try for once to see if there might be something good in systemd, because there's a lot. People tend to be opposed to change, unless the change happens in there very own interest area. I can understand that you are not interested in having the init system change, that you know sysvinit and never felt the need to change it. But please, you need to to understand that this is a very limited view of the world. Progress needs to take place, if there are good reasons for it -- and we have plenty good reasons! If we stay stuck in 80's Unix then we'll not be able to compete, because nobody will be waiting for us. Nobody will. The OS market is moving fast, and so must we. Seriously guys, embrace progress, and help us getting things right. Just sitting there on the mailing list, and complaining when it already is too late anyway and the train already left the station is just not helpful, and makes the lifes of those who care, who do the improvement work hard. It is easy to develop a negative opinion, but I kinda get the feeling that up to 85% of all criticism I get on this unfriendly place that is fedora-devel is simply because the people complaining didn't bother to read the docs, ask around, or even use google. So guys, be more positive. Everybody can be a complain sometimes, but complaining all the time will make people not care for you anymore and will make people just shut off and ignore you. And hell yeah, I am this > < close to it. I am sure you can come with a ton of theoretical attacks on systemd, if you think that calling socket() from PID 1 is indeed the worst thing a program can do on this world. You'll probably be very much alone (or well, you'll probably be joined by the rest of your troupe) in your paranoia however, and if invoking socket() was really that dangerous it probably should be fixed in the kernel. OTOH, if you tried to be positive you could also remove your tunnel vision on theoretic (and in reality non-existing) problems and see the security benefits systemd gives you. We provide packagers, developers, administrators with very very easy hooks to make their services secure (I will blog about this), and we give you all controls to limit resources in almost every possible way in order to avoid DoS, we allow you to flexible jail your services in namespaces. We do this making use of capabilities, namespaces, certain cgroup controllers. We also guarantee execution of all services in pristine execution contexts whith no leaking execution data, and do a ton of other stuff to make things easily securable. And that is an absolute first on Linux, heck even on Unix. I am pretty sure at least that systemd is the first and still only init system that provides you with options like CapabilityBoundingSet= or PrivateNetwork= or ReadOnlyDirectories=. Can you name me even one init system empowering you with powerful (and simple!) tools like this to secure execution of services? Upstart doesn't, sysvinit doesn't, SMF doesn't, launchd doesn't. I am listening! So, if you guys keep repeating that systemd was bloated or insecure then I'll just ignore you because the truth lies very differently: a real systemd system will be smaller and more secure than a sysvinit system. Thank you, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
