This is a rework of v1 with which it doesn't have a single line in common :) This version uses XATTR heavily. The first two patches utilize extended attributes to store the original owner and the reference counter, while the next two are just a proof of concept. They suffer with a serious defect - if there's already an ACL entry for user, we completely overwrite it and dispose. Anyway - I am solving atomicity problem for now. I need to understand virlockd better, so if somebody has a bright idea how to solve locking or somebody is willing to implement it himself, feel free. There are several questions I think we should agree on: - namespace of XATTR labels: There are currently 4 namespaces: security, system, trusted and user. I think trusted suits our needs the best. See man attr(5) for their description. - Is it enough if we keep the original label only on those filesystems supporting XATTR? If so, should we turn libattr into hard dependency? - Keeping the whole logic within XATTR drops need for security driver state XML. But what about those filesystems which does not support XATTR by design? (I don't want to point my finger) - The atomicity problem. I guess we want virlockd however we don't want to enforce users to configure anything in order to use this functionality. But I don't think this can be achieved, if locks need to be shared among other hosts, right? Michal Privoznik (4): virFile: Add APIs for extended attributes handling security_dac: Remember owner prior chown() and restore on relabel virfile: Introduce internal API for managing ACL security_dac: Favour ACLs over chown() configure.ac | 2 + libvirt.spec.in | 6 + src/libvirt_private.syms | 5 + src/security/security_dac.c | 209 +++++++++++++++++++++++++----- src/util/virfile.c | 308 ++++++++++++++++++++++++++++++++++++++++++++ src/util/virfile.h | 19 +++ 6 files changed, 515 insertions(+), 34 deletions(-) -- 1.8.1.5 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list