On 11/03/2015 11:15 AM, Daniel P. Berrange wrote:
[...]
>> still still be spewed? Since virNetDevSetupControlFull:148 is the socket
>> call failure and not the ioctl failure. Sure the caller wouldn't spew a
>> second one, but why would the first one not be spewed?
>
> Empirically I don't see any errors after reverting it. It appears the
> reason for this is that the original code uses AF_LOCAL while the
> virNetDevSetupControllFull uses AF_PACKET, and the latter is restricted
> to only privileged users. If I change the original code to use AF_PACKET
> then it shows errors too. The reason for using AF_PACKET was that it
> was substaintially faster than AF_LOCAL
>
Alternatively in order to not fall into the rabbit hole again...
Can we determine if we're not privileged at the start of
virNetDevSendEthtoolIoctl, eg
if (geteuid() != 0) {
VIR_{WARN|INFO}("cannot set feature in unprivileged daemon");
cmd->data = 0; /* To indicate not found (e.g. lie) */
return 0;
}
or follow virNetDevBandwidthSet which causes an error.
IOW: Should we allow these bits to be set in a non privileged daemon?
And if not should we error on them?
For the concern about the two error messages, just remove the
virReportSystemError from the callers and adjust the ioctl() to:
if ((ret = ioctl(fd, SIOCETHTOOL, &ifr)) < 0) {
virReportSystemError(errno, "%s", _("ethtool ioctl error"));
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list