On 29/12/11 17:40, Christian Boltz wrote:
Hello,
If you re-run the initscript and get the same set of
tempfile names, then something smells very fishy ;-)
Yeah, and FYI, these bugs are very common, and still exist on init scripts today.
I know systemd supports "private /tmp" (IIRC as in "a private subdir of /tmp that looks like /tmp itsself to the process"), and yes, that's a good feature and adds some security. But unfortunately there are some things that _need_ the shared /tmp for some reason (for sockets etc.)
Yes, and those services that need sharing have to run with PrivateTmp=false (which is the current default btw)
And there could also be attackers who inject files in a "private" /tmp/*/ directory after it has been created.
Really ? how ? the kernel won't let you do that, only the process started by systemd has access to those directories...
Instead, the "aa-status" script will give you all you need - including nice $? values. But: *** You have to run it! ***
yeah, and what's the problem documenting that the user has to run aa-status not systemctl status apparmor... to know what's going on ?
Someone could manually unload all AppArmor profiles (by manually running apparmor_parser -R) and systemd would still tell you "apparmor: running" because it was started by systemd.
Not if apparmor notifies systemd that is unloading... sd_notify(3) may help.
Now please tell me which way is smarter ;-)
I would have to look what it does and figure it out. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org