Bug 1161358

Summary: [ACL] polkit: wrong attribute name 'interface_mac' for network interface in the documentation
Product: Red Hat Enterprise Linux 7 Reporter: vivian zhang <vivianzhang>
Component: libvirtAssignee: Pavel Hrdina <phrdina>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: dyuan, eblake, mzhan, phrdina, rbalakri, ydu, zhwang
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-1.2.8-9.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-05 07:47:10 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:

Description vivian zhang 2014-11-07 01:50:19 UTC
Description of problem:
[ACL]When give non-root user right permission using interface mac as filter condition, access always denied for all interface API.


Version-Release number of selected component (if applicable):
libvirt-1.2.8-5.el7.x86_64
qemu-kvm-rhev-2.1.2-3.el7.x86_64
kernel-3.10.0-190.el7.x86_64


How reproducible:
100%

Steps to Reproduce:

1. Enable 'polkit' as the Access control driver.
#vim /etc/libvirt/libvirtd.conf
access_drivers = [ "polkit" ]
 
2. Granted local user permission to connect to libvirt in full read-write mode
 #vi /etc/libvirt/libvirtd.conf
unix_sock_rw_perms = "0777"
auth_unix_rw = "none"

3. Add a normal user
#useradd test1
#passwd test1

4. I use virsh iface-undefine command as example to show the access denied error, other iface command show access denied error too.

Give user test1 the permission to undefine the interface, here we use interface_mac as filter condition in action.lookup
add rule in below file.
# cat  /etc/polkit-1/rules.d/100-libvirt-acl.rules  
polkit.addRule(function(action, subject) {
if (action.id == "org.libvirt.api.interface.delete" &&
        subject.user == "test1") {
          if (action.lookup("connect_driver") == 'QEMU' &&
              action.lookup("interface_mac") == '24:be:05:02:a0:e9') {
            return polkit.Result.YES;
          } else {
            return polkit.Result.NO;
          }
    }
});

5. login with user test1, connect the libvirtd server,
then excute the following command
#su test1
$ virsh -c qemu:///system
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit
virsh# iface-list
 Name                 State      MAC Address
---------------------------------------------------
 eno1                 active     24:be:05:02:a0:e9
 lo                   active     00:00:00:00:00:00

virsh # iface-undefine --interface 24:be:05:02:a0:e9
error: Failed to undefine interface 24:be:05:02:a0:e9
error: access denied

6. check libvirt log find following error.
2014-10-23 08:40:47.151+0000: 2041: debug : virAccessDriverPolkitCheck:152 : Check action 'org.libvirt.api.interface.delete' for process '12428,1650015,1002'
2014-10-23 08:40:47.151+0000: 2041: debug : virCommandRunAsync:2398 : About to run /usr/bin/pkcheck --action-id org.libvirt.api.interface.delete --process 12428,1650015,1002 --detail connect_driver QEMU --detail interface_name eno1 --detail interface_macaddr 24:be:05:02:a0:e9
....
2014-10-23 08:40:47.152+0000: 2041: debug : virCommandRunAsync:2401 : Command result 0, with PID 14643
2014-10-23 08:40:47.157+0000: 2041: debug : virCommandRun:2249 : Result fatal signal 1, stdout: 'connect_driver=QEMU
interface_macaddr=24\72be\7205\7202\72a0\72e9
interface_name=eno1
....
2014-10-23 08:40:47.158+0000: 2041: error : virInterfaceUndefineEnsureACL:5363 : access denied


7. the same result also access denied when setting right action.id using interface_mac as filter condition
#virsh iface-start eno1
#virsh iface-destroy eno1
#virsh iface-define eno1


Actual results:
when I use interface_mac as action.lookup condition to give non-root user the right permission manage interface API, but access denied for all interface API command as above


Expected results:
1.When using interface_mac as action.lookup condition for non-root user, run interface API command return success, no access denied. Libvirt can match the right interface_mac value and authorize non-root user the right permission to manage interface.

2.When access denied happened, libvirt log can print out the exactly action id which is needed. It is useful for tester.
log should be print as below:
2014-10-23 06:29:36.962+0000: 11805: error : virAccessDriverPolkitCheck:177 : access denied: Policy kit denied action org.libvirt.api.interface.delete from 10824,18689289,1000: exit status 1.
It has already been provided in rhel7 libvirt-1.1.1-29.el7.x86_64 build, but discard now.

Additional info:

vivian zhang

Comment 2 Eric Blake 2014-11-07 09:58:41 UTC
Fix upstream:
commit d53d52d4c0299f5161bdeeccc925169d68ac990f
Author: Luyao Huang <lhuang>
Date:   Fri Nov 7 17:35:33 2014 +0800

    doc: fix mismatched ACL attribute name
    
    As documented in https://bugzilla.redhat.com/show_bug.cgi?id=1161358,
    the ACL attribute should be named: interface_macaddr
    
    Signed-off-by: Luyao Huang <lhuang>
    Signed-off-by: Eric Blake <eblake>

Comment 3 Pavel Hrdina 2014-11-24 12:42:59 UTC
As the commit in comment 2 shows there is wrong attribute name in the documentation so it should be 'interface_macaddr' instead of 'interface_mac' so the polkit behaves correctly. I've updated the bug summary and will backport the patch to fix the documentation.

Comment 6 zhenfeng wang 2014-12-01 07:26:05 UTC
I can reproduce this issue with comment0's steps with libvirt-1.2.8-5.el7.x86_64, and the issue has gone while update the libvirt to libvirt-1.2.8-9.el7. however i have another doubt that why we change the error info in rhel7.1 while the user didn't have permision to excute one api, i found it more readable in rhel7.0, I'm a little confused about it, can you give us some explanation? thanks

The following was an example while user didn't have permission to edit the guest's xml (need 3 permissions: write+save+read-secure); From the rhel7.0's error info we could know which specific permission the user need while the user fail to operate the api, however the rhel7.1 isn't as clear as the rhel7.0 

In rhel7.0, we will have 3 different errors info while fail to edit the guest's xml

2014-12-01 07:23:11.730+0000: 29336: error : virAccessDriverPolkitCheck:177 : access denied: Policy kit denied action org.libvirt.api.domain.read-secure from 5437,522450,1008: exit status 1
2014-12-01 07:23:11.730+0000: 29336: error : virAccessManagerSanitizeError:203 : access denied
2014-12-01 07:23:11.730+0000: 29336: error : virAccessManagerSanitizeError:203 : access denied
2014-12-01 07:23:43.957+0000: 29344: error : virAccessDriverPolkitCheck:177 : access denied: Policy kit denied action org.libvirt.api.domain.write from 5437,522450,1008: exit status 1
2014-12-01 07:23:43.957+0000: 29344: error : virAccessManagerSanitizeError:203 : access denied
2014-12-01 07:23:43.957+0000: 29344: error : virAccessManagerSanitizeError:203 : access denied
2014-12-01 07:24:07.936+0000: 29339: error : virAccessDriverPolkitCheck:177 : access denied: Policy kit denied action org.libvirt.api.domain.save from 5437,522450,1008: exit status 1
2014-12-01 07:24:07.936+0000: 29339: error : virAccessManagerSanitizeError:203 : access denied
2014-12-01 07:24:07.936+0000: 29339: error : virAccessManagerSanitizeError:203 : access denied



In rhel7.1, it will only report the following 2 errors while user didn't have permission to operate that api

2014-12-01 06:58:52.597+0000: 27140: error : virDomainGetXMLDescEnsureACL:2925 : access denied

2014-12-01 07:09:07.534+0000: 27146: error : virDomainDefineXMLEnsureACL:2131 : access denied

Comment 7 zhenfeng wang 2014-12-01 08:04:12 UTC
I could see more details about the acl permission deny while set the log_level=1,  please ignore the comment6's issue, since all issues in this bug
has been fixed, so mark this bug verifed

Comment 9 errata-xmlrpc 2015-03-05 07:47:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0323.html