Hi, thanks for your analysis. Daniel P. Berrange wrote: > There are lots of scenarios to consider > > - Direct local API usage. You have the PID, UID & GID of the process > - Local usage via libvirtd + UNIX sockets. You can get the PID, UID & GID > of the client end using the SCM_CREDENTIALS message. (see man 7 unix) > - Remote usage via libvirtd + TCP sockets. Depending on the security & > encryption settings you may have a SASL username, or a x509 certificate > CNAME, or both, or neither. > - Local usage via libvirtd + UNIX sockets + libvirt-qpid. The PID, UID > & GID of the client end aren't particularly usage, since libvirt-qpid > is just a demon running as root, which accepts calls on behalf of many > remote apps. Does QPid provide any identifying info about the entity > which put the message on the queue. I'm not familier with Qpid. Could you explain its benefit or point me some documents about it? And how can I use it on libvirt? > - Remote usage with IPSec ? I personally don't like IPSec because it's too rigid. And I don't know whether it is common. X509, SASL, or password authentication through secure connection seems simple and good enough. > > So there are multiple identifying credentials, in multiple formats, and > need some way to associate this information with a connection. > > Applying RBAC to local (non-Daemon) API usage has clear limitations - if > the user running virsh (or equiv) has direct access to the system, then > they could trivially just replace the real virsh with their own virsh > without RBAC. So RBAC usage in the non-Daemon context is only useful > if the user does not have direct access to the ssytem (eg, virsh is being > invoked on their behalf by another tool, or a constrained environment > where its guarenteed they can't provide their own libraries/binaries. That's true but, as I mentioned in the other e-mail, I'm now concentrating on AC itself assuming that user-auth has been established. I don't think user authentication and access control should be tied up with each other. I mean, it's nice if AC-module can always use uid as a part of the key for consulting policies, not depending on whether libvirt is running on a local or remote server. > >> The best way would be to link some user-auth data with the virConnectPtr, >> but becomes a bit trickier when authentication is done prior (like in >> remote case) to virConnectOpen. > > The key question is do we need to pass the client/callers identity at > the time we create the connection object, or is it sufficient to > provide it after the fact with a call like > > virConnectAddSecParam(VIR_SECPARAM_UNIX_UID, getuid()); > virConnectAddSecParam(VIR_SECPARAM_UNIX_GID, getgid()); > virConnectAddSecParam(VIR_SECPARAM_USERNAME, saslUsername); > virConnectAddSecParam(VIR_SECPARAM_X509_CNAME, saslUsername); A simple question. How do you identify what user the remote libvirt switches to? Do you look up some directory services? Hiroya > > Or do we need to provide this info via some form of callback mechanism, > perhaps via the exiting virConnectCredential struct, which is curently > not used on the server end of remote connections. > > Daniel -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list