Lennart Poettering wrote: > Do you happen to know why /var/run doesn't have nodev,noexec set too?
No, I'm afraid not. > I have now added all three options to both mounts for all distros, as I > think all distros oculd benefit equally from it. I figure people will > report back if that breaks something... OK. I certainly can't think of a valid use case for device files or executables under /var/run. >> The "showthrough" option is Upstart specific but the remaining >> options should be honoured. > > Hmm, just out of curiousity, do you know what it does? "showthrough" permits a mountpoint to be mounted before its parent mountpoint. E.g. if /var is a separate filesystem, the /var/lock tmpfs will be created first under the root filesystem and then moved under /var once /var is mounted. I haven't looked at the source to figure out how this is actually implemented. > I have decided not to merge this part for now. I'd much prefer if ubuntu > would adopt the lock group too, since everything else appears to be a > security nightmare to me. Also note that Ubuntu and Debian are in the > same boat here, so if we merge some fix for this I want something that > covers both cases. I agree that the lock group approach seems better from a security point of view but the fact is that Debian/Ubuntu doesn't have that group at present. My current focus is on getting Ubuntu fully booted under systemd and I don't want to take on the task of eliminating a lot of pre-existing differences between distros just at the moment. Something like this would really need to be introduced in Debian first anyway, and then flow downstream to Ubuntu. Since you don't want the ifdefs in the upstream source, I'll just override that particular unit file in the Ubuntu packaging for now. I considered that approach anyway but thought I would at least try for an upstream patch. > Andrew, are your .debs based on Michael's/Tollef's Debian .debs? For this version I started with the latest upstream git source and then added the Debian packaging from Tollef's git repository. That seemed the best approach in the short term since it gives me a chance of sending some upstream patches that will apply cleanly. As this matures, I would expect to fall back to the usual Ubuntu approach of basing the Ubuntu package on a released Debian package. -- Andrew Edmunds [email protected] _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
