Closed draconicfae closed 1 year ago
This makes a lot of sense to me. Or do we have any sort of compatibility reasons not to @dvdhrm ?
Sorry for making you trace this to the code! The reason we used EPERM
(or the respective DRIVER_E code) is that when the driver was mostly a stub we wanted to avoid introducing compatibility-issues to dbus-daemon, and thus EPERM
was a nicely compatible way, because clients need to be able to deal with it, anyway (or fail on it, however they decide).
However, these days only the Stats
interface has stubs, so I think it is reasonable to use UNIMPLEMENTED
as an error-description. I filed #307 to adjust for this.
(Fixed in #307.)
I'd love to see a new driver.c error string for unimplemented methods. Something like [DRIVER_E_UNIMPLEMENTED] = "This method is not implemented yet"
I wasted time going down a security policy rabbit hole when I got "The caller does not have the necessary privileged to call this method" and ended up cloning the dbus-broker repo to trace what changes I'd need to make to give the caller sufficient privileges, only to discover that DRIVER_E_PEER_NOT_PRIVILEGED is the code used for two fully stub methods and another basically-stub method, meaning it's not actually a matter of insufficient privileges.