Description of problem: Logs too much Version-Release number of selected component (if applicable): # rpm -q systemd systemd-219-19.fc22.x86_64 How reproducible: See /var/log/messages Actual results: See below Expected results: No such nonsense about world readability as most of the stuff runs as root anyway: # ps -ef|grep systemd root 1 0 0 Jul01 ? 00:00:33 /usr/lib/systemd/systemd --system --deserialize 19 root 847 1 0 Jul01 ? 00:02:14 /usr/lib/systemd/systemd-journald root 1351 1 0 Jul01 ? 00:00:09 /usr/lib/systemd/systemd-logind dbus 1356 1 0 Jul01 ? 00:01:32 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation root 1427 1 0 Jul01 ? 00:00:00 /usr/lib/systemd/systemd --user gdm 2219 1 0 Jul01 ? 00:00:00 /usr/lib/systemd/systemd --user udo 2561 1 0 Jul01 ? 00:00:00 /usr/lib/systemd/systemd --user root 2699 1 0 15:46 ? 00:00:00 /usr/lib/systemd/systemd-udevd root 3210 3860 0 15:53 pts/0 00:00:00 grep --color=auto systemd So please spare us the noise and bother your time with the real problems that have been mentioned before and are still open. Additional info: Jul 9 15:46:36 suffedoos systemd: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
The auditd.service should be installed with 644.
What does that help if the process runs as root? Missing world-permissions appears to me as a non-issue.
The file permissions are the way they are for common criteria purposes. We can either close this as not a bug or transfer it to systemd if you want it to quit logging this. Honestly, I have no idea why systemd would care except to just make people angry.
https://github.com/systemd/systemd/issues/770
Well, not a systemd bug that is.
Systemd logs way too much. Systemd has messed up the logging. Consider the separation of the former .xsession-errors from the /var/log/messages file. (and no, I do not need a journal) That would make life a lot simpler and easier. Please consider the useless logging (starting..., started.. etc) where just an OK thing and an error in the case of error would suffice. Especially this permission message is worse than all that as it is useless. systemd runs root, systemd runs as usual (cannot find rootlv since fc22 ) and nothing is done to the source or the rpm when someone notices.
*** Bug 1247748 has been marked as a duplicate of this bug. ***
Steve Grubb, you say that: "The file permissions are the way they are for common criteria purposes." Could you please elaborate what the common criteria purposes are for setting the permissions on the audit unit file differently from all other unit files? I am curious if there is a good reason to try and hide the unit file contents from non-privileged users, unlike the contents of all other unit files. Besides, systemd warns that even setting the unit file non-world-readable, its contents can still be accessed by non-privileged users through the API's, so we could just as well set the permissions to 0644 right away. I do think it is best practice to make everything that has no security/privacy-concern world readable, as this enables most basic maintenance tasks to be done as non-privileged user. Setting it to 0640 forces an administrator to use the root account or sudo for the simple task of seeing the contents of this file, even though there is no apparent reason to keep any of it secret.
A safer system would not disclose any system related configurations of any kind to any user. If the sysadmin had thought of giving access to these configurations to a user then she would have put the user in a certain group.
Right, well I believe that a consistent state of the Fedora environment is most important. So either change the permissions of audit to 0644 (for the same reasons that the other people had for setting those permissions for all other unit files) Or change the permissions of all other unit files to 0640 (for the "common criteria purposes" and reason mentioned by udo). In my humble observation by the way, even though udo's argument makes some sense, this is definitely not the way Fedora is designed today. If you look at the permissions of all files in the system, you can see a very clear pattern: if there is a good reason to hide it, it's hidden; if not, it is readable by default. Even though some may not agree with this design choice, it is more important to keep the ecosystem consistent, than it is to enforce your personal preference in the few packages that you happen to maintain.
I'm reopening this as audit bug. Sorry for closing the bug as (systemd) NOTABUG while the package was assigned to audit.
*** Bug 1266733 has been marked as a duplicate of this bug. ***
This isn't a system configuration though. This file is world-readable in the sense that you can just download the RPM and find that out (because overriding it involves writing directly to /etc, not changing this file). Plus, any arguments on the command line are readable in /proc anyways. That's besides systemctl show auditd showing all kinds of info. Now audit.conf shouldn't be world-readable, but that's not what this bug is about.
OS PP v4.0 changes a lot of requirements. As we get ready to meet that PP I'll relax the permissions. It'll probably be the 2.5 audit package release which is isgoing to be done in the next month or so.
*** Bug 1286716 has been marked as a duplicate of this bug. ***
Fixed in audit-2.5.
I'd argue that it's still an issue if you create a unit file in /etc and you are strict about permissions (e.g. my systems run with default umask 077, so if I need to make something readable to other group/users I will explicitly specify that). The behaviour systemd tries to promote is against the least privilege principle (as well as the comment from Erik) -- the system should not expose something if there is no need for that. Otherwise we will end up with something accidentally exposed.