The "issue" is when using a remote URI and authn when attempting to connect to the local system when a local URI and usage of pkttyagent was "expected" for local authn. The current bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1374126 which was "forked off" from: https://bugzilla.redhat.com/show_bug.cgi?id=986365 which added the support for pkttyagent processing for "local" authn when the GUI option wasn't available (e.g. when ssh@localhost, run virsh) in order to perform the authn of the user. This is one of those "either" patch 1 or patch 2 will fix the problem, but I really couldn't decide which I liked better. I'm leaning towards the second one only because of the one authn failure; however, I'm not sure I like the escape path comparison to ":///". With only the first patch one would get two challenge/responses before failure, e.g.: $ virsh -c qemu+ssh://someuser@localhost/system list --all someuser@localhost's password: someuser@localhost's password: error: failed to connect to the hypervisor error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage' $ With the second patch one would get one challenge/reponse before failure e.g.: $ virsh -c qemu+ssh://someuser@localhost/system list --all someuser@localhost's password: error: failed to connect to the hypervisor error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage' $ Going with #2 restores essentially older (e.g. 1.3.4) processing when the pkttyagent processing loop didn't exist. The challenge/response in either case comes from ssh and is successful; however, code in remoteDispatchAuthList doesn't let a non root user to take this URI option for a local authn/authz because the callerUid is not 0 (root). Although, I suppose it would be possible to check whether the @callerUid was authorized (e.g. part of some group), but that I think "outside" the scope of what the bz is reporting, so I didn't take that route. The reality is the bug is mostly a problem for non UI type processing where providing that ctrl-c to quit isn't as likely/possible. John Ferlan (2): virsh: Track when create pkttyagent virsh: Don't attempt polkit processing for non local authn/authz tools/virsh.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) -- 2.9.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
ping? Tks - John On 05/11/2017 11:04 AM, John Ferlan wrote: > The "issue" is when using a remote URI and authn when attempting to connect > to the local system when a local URI and usage of pkttyagent was "expected" > for local authn. > > The current bug is: > > https://bugzilla.redhat.com/show_bug.cgi?id=1374126 > > which was "forked off" from: > > https://bugzilla.redhat.com/show_bug.cgi?id=986365 > > which added the support for pkttyagent processing for "local" authn when > the GUI option wasn't available (e.g. when ssh@localhost, run virsh) in > order to perform the authn of the user. > > This is one of those "either" patch 1 or patch 2 will fix the problem, > but I really couldn't decide which I liked better. I'm leaning towards > the second one only because of the one authn failure; however, I'm not > sure I like the escape path comparison to ":///". > > With only the first patch one would get two challenge/responses before > failure, e.g.: > > $ virsh -c qemu+ssh://someuser@localhost/system list --all > someuser@localhost's password: > someuser@localhost's password: > error: failed to connect to the hypervisor > error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage' > $ > > With the second patch one would get one challenge/reponse before failure e.g.: > > $ virsh -c qemu+ssh://someuser@localhost/system list --all > someuser@localhost's password: > error: failed to connect to the hypervisor > error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage' > $ > > Going with #2 restores essentially older (e.g. 1.3.4) processing when the > pkttyagent processing loop didn't exist. > > The challenge/response in either case comes from ssh and is successful; > however, code in remoteDispatchAuthList doesn't let a non root user to > take this URI option for a local authn/authz because the callerUid is > not 0 (root). Although, I suppose it would be possible to check whether > the @callerUid was authorized (e.g. part of some group), but that I think > "outside" the scope of what the bz is reporting, so I didn't take that route. > > The reality is the bug is mostly a problem for non UI type processing > where providing that ctrl-c to quit isn't as likely/possible. > > John Ferlan (2): > virsh: Track when create pkttyagent > virsh: Don't attempt polkit processing for non local authn/authz > > tools/virsh.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
ping^2? One option or the other? Tks - John On 05/17/2017 06:57 AM, John Ferlan wrote: > > ping? > > Tks - > > John > > On 05/11/2017 11:04 AM, John Ferlan wrote: >> The "issue" is when using a remote URI and authn when attempting to connect >> to the local system when a local URI and usage of pkttyagent was "expected" >> for local authn. >> >> The current bug is: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1374126 >> >> which was "forked off" from: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=986365 >> >> which added the support for pkttyagent processing for "local" authn when >> the GUI option wasn't available (e.g. when ssh@localhost, run virsh) in >> order to perform the authn of the user. >> >> This is one of those "either" patch 1 or patch 2 will fix the problem, >> but I really couldn't decide which I liked better. I'm leaning towards >> the second one only because of the one authn failure; however, I'm not >> sure I like the escape path comparison to ":///". >> >> With only the first patch one would get two challenge/responses before >> failure, e.g.: >> >> $ virsh -c qemu+ssh://someuser@localhost/system list --all >> someuser@localhost's password: >> someuser@localhost's password: >> error: failed to connect to the hypervisor >> error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage' >> $ >> >> With the second patch one would get one challenge/reponse before failure e.g.: >> >> $ virsh -c qemu+ssh://someuser@localhost/system list --all >> someuser@localhost's password: >> error: failed to connect to the hypervisor >> error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage' >> $ >> >> Going with #2 restores essentially older (e.g. 1.3.4) processing when the >> pkttyagent processing loop didn't exist. >> >> The challenge/response in either case comes from ssh and is successful; >> however, code in remoteDispatchAuthList doesn't let a non root user to >> take this URI option for a local authn/authz because the callerUid is >> not 0 (root). Although, I suppose it would be possible to check whether >> the @callerUid was authorized (e.g. part of some group), but that I think >> "outside" the scope of what the bz is reporting, so I didn't take that route. >> >> The reality is the bug is mostly a problem for non UI type processing >> where providing that ctrl-c to quit isn't as likely/possible. >> >> John Ferlan (2): >> virsh: Track when create pkttyagent >> virsh: Don't attempt polkit processing for non local authn/authz >> >> tools/virsh.c | 10 +++++++++- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.