Bug 2115153

Hello,
could please provide the output of `getfacl /var/lib/libvirt/images`?  I can't verify the (in)correctness of the ACL on the copied file without the knowledge of default ACL set on its parent directory.  Also, I would like to stress that I'm a maintainer of libacl and not of virt-install (package that contains virt-clone) so it's possible that virt-clone does some ACL magic on its own that is out of my reach.

Additionally, the only difference between the actual and expected results in your report are the two lines with `#effective:---`.  That is correct (at least in relation to the ACL entries themselves) because the `mask::---` restricts both permissions of named users/groups and permissions of the owning group.  If you want to suppress the output of effective rights, you can pass `-E` to `getfacl`.

Hello,

the mask and default mask should not restrict anything as they're "rwx" [1]. I don't know if virt-clone does any ACL magic on its own but it doesn't look like it. When I just use virt-clone there are no ACLs on /var/lib/libvirt/images/ or on any files in that directory. All ACLs are a result of me applying them with setfacl AFAIK.

I agree that the correct behavior of "---" mask is to restrict both permissions of named users/groups and permissions of the owning group. However I don't understand why the clone1.qcow2 file has that mask set to begin with. The parent directory has a default mask of "rwx" so I'm expecting for it to be inherited by clone1.qcow2's mask.

Btw I only really care for the "rw-" permissions to be applied, I included "x" as a result of sloppiness. I want the "rw-" permissions to be applied on all files created in /var/lib/libvirt/images/ but for some reason that doesn't happen for files created by virt-clone.



[1]
[root@myhost1 ~]# getfacl /var/lib/libvirt/images/
getfacl: Removing leading '/' from absolute path names
# file: var/lib/libvirt/images/
# owner: root
# group: root
user::rwx
group::--x
group:johnd:rwx
mask::rwx
other::--x
default:user::rwx
default:user:johnd:rwx
default:group::--x
default:group:johnd:rwx
default:mask::rwx
default:other::--x

Thank you for the information!

I tried the reproducer and got the same results.  Upon further inspection, I found out that libvirt's default mode for storage volumes is 0600 [1] and this mode also seems to be (re)set during cloning.  When the ACL mask entry is present it corresponds to the permissions of the owning group for the ACL unaware tools.  Thus, cloning the mode sets the following ACL entries which correspond to the results you've provided: user::rw-, mask::---, other::---

This behaviour is correct from the point of ACL.  Therefore, I'm going to reassign this bug to the virt-manager component (which contains virt-clone) for further inspection.

[1] https://github.com/libvirt/libvirt/blob/3d5245e3ebd1e143ea858c8535474b681bc21a38/src/storage/storage_util.h#L152

virt-clone largely uses libvirt APIs for storage duplication, so libvirt would need new support here, so reassigning.

These days the libvirt storage code does not see much new development these days though, so I don't expect this to be fixed any time soon, if ever

Fix proposed upstream: https://github.com/virt-manager/virt-manager/pull/564

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.