On Wed, 2011-08-24 at 09:05 -0400, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/23/2011 10:58 PM, Kevin Kofler wrote: > > Steve Grubb wrote: > >> I think it was mentioned before that systemd is consuming a lot > >> of memory. > > > > The amount quoted was actually ridiculously small considering both > > today's memory sizes and the fact that systemd is a singleton > > process. > > > > Plus, it can be reduced even further (by something like 90%!) by > > disabling SELinux. It's your security stuff which is consuming a > > lot of memory. > > > > Kevin Kofler > > > Well not wanting to get into this war, this is a little bit of the > chicken and the egg. The reason systemd has SELinux memory usage is > because it wants to take on the functions that used to be done by > other processes, like udev labeling of /dev. Impersonating processes > requires SELinux labeling, while listening on sockets. Creating of > content on tmpfs /run requires SELinux Labeling. > > So saying systemd has grown because of SELinux is stretching the truth > a little. I think you can say it is a plain lie, it's neither fault. Systemd took over some functions done by other processes so the memory is used by systemd and not by these other processes. It is a shift in which process uses what. It is true this memory is then carried around by systemd forever, but that's not a big deal. It saves a lot of time on process activation for changes that need to happen on the fly and when not used the kernel is perfectly capable of swapping out whatever is not needed. Yay for memory overcommitting kernels! And before people wonder if I am one of 4/5 try to shot systemd down, I am not. I think it has very good features, and just need to round some rough edges in order to make it easier to transition. And I say this even though systemd is giving my group a headache because there is a strong disconnect between the way it works and the way we start services in a sysv environment. > With that said, I like some of the features that systemd is bringing > to the table, from a security point of view. /me too! > Setting up CGroups properly. > Always starting services with a clean environment, IE the parent of a > service is init rather then some random admin that happened to restart > it. This is a truly good feature, the amount of pain people go through with SELinux because old init files carried the admin user context around instead of setting up the proper context is gone. Even people that knew what was going on were tricked regularly by this insanity, and it was all due to a very poor init system. > SELinux has tons of AVC's over the years caused by an admin sitting in > a random directory like /home/dwalsh or /root and starting a service. > Lots of bugs have had to be fixed by services using the environment > of the admin. Don't forget mismatching labels on files due to this and then the service fails to start at boot because at that point it is started with the right SELinux label and it is prevented access to its own files (just like it happens with some daemons when they are started as roo by mistake and then they refuse to work if you start them with their own users because their files are owned by root and not r/w by the unprivileged daemon user). > Allowing us to potentially eliminate all services from ever talking to > a tty. Another really goos thing! > I have railed over the years about random root running daemons using > /tmp, and I think systemd using namespacing to change a services view > of /tmp is a good idea. > > I think using namespacing to eliminate the network is also a good > idea, especially when combined with SELinux. Yes, we still need some change for stuff that unfortunately relies on /tmp like kerberos credentials caches. I hope we'll be able to move them under SSSD control soom so that will be one less problem on the road to make private, per-user, /tmp dirs. > One think we need to code up is some additional knowledge into systemd > to say which Types can manage which services. For example we want to > say NetworkManager_t can start/stop ntpd but not start/stop the apache > server. Similarly we want to have a confined admin type webadm_t that > can only start and stop the apache service. In Fedora 14/15 we do > this by labeling the initrc script. Excellent! Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
