Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1691875 - No way to read the serial console log files as non root
Summary: No way to read the serial console log files as non root
Status: NEW
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2019-03-22 17:35 UTC by Attila Fazekas
Modified: 2019-03-25 15:19 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:

Attachments (Terms of Use)

Description Attila Fazekas 2019-03-22 17:35:48 UTC
I am using console log files with my libvirt domains and I am also using some features which requires elevated permissions therefore my users are in the libvirt group.

<console type='file'>
      <source path='{path}'/>
      <target type='serial' port='0'/>

Looks like the log file is created by libvirt with root owner, root group and mode 0600.
I would like to be able to read those files as user(s).

POSIX ACL cannot workaround the the issue the group/other permissions
masks all inherited permissions.

Solution 1:
- Allow to define the desired mode and user/group in the libvirt.xml -s.

Solution 2:
- use 0640 or 0644 instead of 0600, typically nobody else than root is member of the root group at least it would allow me to define a POSIX ACL only once.

NOTE1: The qcow2 files permission set to 0644 root:root, why the console log files needs to be more strict ?

The log files outside of the user home.

Comment 1 Attila Fazekas 2019-03-23 10:09:22 UTC
Second round, trying less privileges (again):

With the session connection the logfile is owned by the user with 600.
The first thing which fails:
I cannot use the arbitrary networks created by the qemu:///system .

On single user machines it can be good enough.
I'll try mixing the two connection type usage.

Comment 2 Attila Fazekas 2019-03-25 07:18:45 UTC
/etc/qemu/bridge.conf usage feels less secure than just allowing the users in the libvirt group
to touch the networks.
My bridges are prefixed so rules with user/group name pattern, would be better.

The session connection has issues with ovs and hostdev,
probably easier solution to somehow made the  log files user readable, than
adding a full authorization model for all stuff for the session users.  

In case the solution is allowing the system user to specify mode,
the user(s) should not be able to set the log file to be executable or using the 07000 bits.

In case we just hardcode 0644 instead of 0600, the users
will have space on the log file containing directory to allow or deny

Comment 3 Attila Fazekas 2019-03-25 08:48:16 UTC
Typical the members of the libvirt group are allowed to use qemu:///system ,
Just changing the group of the log file to libvirt and
 adding group read permission for libvirt group can be also good. 

In this case I only need to use change default posix acl on the containing directory,
when I want to share the logs outside the libvirt group. (I have no such intention ATM.)

Note You need to log in before you can comment on or make changes to this bug.