On Mon, 18 Jul 2011, Bastien ROUCARIES <roucaries.bast...@gmail.com> wrote: > Yes but 793691kb of unkillable even by -9 signal is not really nice.
root 1 0.0 1.0 4348 2844 ? Ss May26 0:56 /bin/systemd --log-level info --log-target syslog-or-kmsg --system --dump-core --show- status=1 --sysv-console=1 --deserialize 19 Unless systemd locks it's memory (and /proc/1/maps suggests not) then that will all be demand-paged and probably not much will be used on most systems. The above is from the ps output from one of my test i386 systems. root 1 0.0 0.0 2024 132 ? Ss Jan28 5:16 init [2] The above is from the ps output of one of my i386 servers running Squeeze. It appears that systemd has allocated an extra 2324K of RAM and has an extra 2712K resident. Given that it's difficult to buy a phone with less than 256M of RAM nowadays that doesn't seem to be a big problem, and systemd can save memory by removing the need to run other daemons. > Better security will need to keep pid==1 to some really simple stuff, > and delegate funky stuff to another daemon. pid == 1 should be keep > only to reap zombie process no more. I think you mean to say that there is a theoretical benefit for reliability there. As all the things that systemd does will be performed by different root owned processes in a typical Linux system there won't be much potential for security benefits in using separate processes. Even with the most strict configuration of SE Linux the ability to constrain things such as autofs which can be included in systemd isn't a huge benefit as it's extremely difficult to constrain them to prevent attack. If your autofs decides to mount an untrusted device (be it removable media or network) and allow device nodes and/or SUID binaries then you're going to lose. Finally vmlinuz is 2.3M compressed on Squeeze and it has a huge amount of code used for modules. If a serious bug is found in any of that code then nothing will save you. I don't think that systemd is the security issue. You could have a HURD system running SE Linux to constrain it's device drivers which is similar to some research projects that preceded SE Linux and is quite possible to implement if someone has enough coding time. On such a system systemd might comprise a significant portion of the code that is highly trusted. So I would be a lot more inclined to accept an argument for sysvinit over systemd if it was based on a SE-HURD platform. But SE-HURD doesn't exist at this time and seems unlikely to exist in the next few years. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201107182313.00615.russ...@coker.com.au
