systemd requires HTTP server and serves QR codes

Matthew Miller mattdm at fedoraproject.org
Tue Oct 9 14:31:24 UTC 2012


On Tue, Oct 09, 2012 at 04:05:10PM +0200, Lennart Poettering wrote:
> On Tue, 09.10.12 09:49, Matthew Miller (mattdm at fedoraproject.org) wrote:
> > allowing regular users to do so. (Commonly currently accomplished by making
> > /var/log/messages owned and readable by the wheel group.)
> The HTTP thingy is not really how admins should access the logs. They
> should just use journalctl.

On a related but tangental note: I notice that journalctl allows access to
members of the admin group by default. In Fedora for the past few releases
we've followed the tradition of making "wheel" the admin group -- see
http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/sn-firstboot-systemuser.html
This is also the case in RHEL 6, so changes here have downstream
implications.

(Apparently Apple does the same thing? Not that that's directly relevant,
but we're not completely out in the weeds here.)

Could we make that a default on Fedora in addition to adm? (I assume this is
polkit but can't see it offhand -- hmmm... looks to be hard-coded in the
source?) I don't really have a strong opinion about whether adm should work
or not, but wheel should.

Second, there's a traditional separation between /var/log/secure and
/var/log/messages. Crucially, the "secure" log may contain
accidentally-typed user passwords and other privacy-sensitive information.
How can we do something similar with the systemd journal and journalctl?

Ideally, the /var/log/messages data would be available to members of the
admin group without extra authentication, but seeing the potentially-privacy
sensitive /var/log/secure should require re-authentication. (As a sysadmin,
I should be able to safely look at message data with a user looking over my
shoulder, so I can help them without possibly exposing private information
about other users on the system.)

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm at fedoraproject.org>


More information about the devel mailing list