Bug 864615
| Summary: | RFE: allow read access to journal files to "wheel" in addition to "adm" | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matthew Miller <mattdm> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | gholms, johannbg, lnykryn, metherid, mschmidt, msekleta, notting, plautrba, systemd-maint, vpavlin |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-04-15 17:18:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Since this is policy related, ideally there would be configuration options covering whether reauthentication is required, and most ideally, giving access to most system messages without extra authentication but requiring it for potentially privacy-sensitive log messages, in analogy to: $ ls -l /var/log/messages /var/log/secure -rw-r----- 1 root wheel 78514 Oct 9 14:34 /var/log/messages -rw------- 1 root wheel 684571 Oct 9 14:35 /var/log/secure Right now, the new system (assuming s/adm/wheel/) is akin to doing: $ ls -l /var/log/messages /var/log/secure -rw-r----- 1 root wheel 78514 Oct 9 14:34 /var/log/messages -rw-r----- 1 root wheel 684571 Oct 9 14:35 /var/log/secure Which is a policy change we don't want to make unintentionally. On the Fedora-devel mailing list, Toshio makes in excellent point:
>> Well, we could of course add this as ACL, but I wonder if it wouldn't be
>> nicer to declare that "adm" is for seeing, and "wheel" for doing as I
>> suggested above.
>>
>If so... usually people want to look at doing as a superset of seeing. We
>talk about read-only vs read-write a lot more than read-only vs write-only.
Which argues for leaving adm (could be used for read-only) and adding wheel (which would then be both "doing" and "seeing").
So, here's what I propose. At the time we turn on persistent logging in F19 (i.e. create /var/log/journal by default), we simply set a default ACL on /var/log/journal, from the postinst script, like so: setfacl -d -m g:wheel:r /var/log/journal Using this default ACL (i.e. the emphasis is on -d here) should be sufficient to make sure all files and dirs created in this dir can be read by "wheel". This way ACL management is done the Linux way with the FS ACL logic tools rather than having explicit options for this and admins can easily build on top of this. While this would work, it would still need documented - I don't know that all admins expect ACLs to be used for 'general' system files. The only place they're used on a normal system right now is for device access in /dev, if I'm remembering things correctly. (In reply to comment #4) > While this would work, it would still need documented - I don't know that > all admins expect ACLs to be used for 'general' system files. The only place > they're used on a normal system right now is for device access in /dev, if > I'm remembering things correctly. I'll add something about this to the man page of journald (including an example, given that ACL semantics are kinda convoluted). I really care about the results rather than the implementation details, but because of the convoluted syntax and because of normal expectations for system files as Bill mentions, I wonder if the ACL solution falls under what a friend of mine calls "a little bit too clever". I'd really like Fedora documentation (including the man pages) to explain that wheel will work, as well as the message journalctl gives when you're not a member of the appropriate group. Otherwise, it feels a little bit like journalctl is foreign object that we've done a bad job of shoehorning in to our distribution. systemd git will now set FS ACL's on /var/log/journal by default, for both "wheel" and for "adm". The journal files are now owned by "systemd-journal" instead, which is a new group which can be used by software that wants access to just the journal, and nothing else, which is stricter than "adm" or "wheel". For example, systemd-journal-gatewayd now uses this group to get access to the journal. I also documented the FS ACL logic in the systemd-journald.service(8) man page. I guess this settles this bug. systemd-201-2.fc18.1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1 Package systemd-201-2.fc18.2: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.2' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.2 then log in and leave karma (feedback). Adding this BZ to the F18 update was my mistake. We do not create a persistent journal by default in F18. |
The journalctl command uses group membership to determine whether to show system logs. From the man page: All users are granted access to their private per-user journals. However, by default only root and users who are members of the adm group get access to the system journal and the journals of other users. The adm command is hard-coded in journalctl.c In Fedora and in RHEL, we use the `wheel` group for administrators. The journalctl command should use this. (I have no strong opinion on whether it should also use `adm`.) One could argue that there's lots of nice colors for administrative sheds, but this is the color we've painted ours. See: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Securing_Your_Network.html#sect-Security_Guide-Workstation_Security-Administrative_Controls and http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/sn-firstboot-systemuser.html and tons of third-party documentation.