Closed ford-prefect closed 1 month ago
Hi! Thanks for the report. Do you have SELinux enabled? Does it work with it disabled?
@dvdhrm yeah, I suspect it needs some policy to let the fd be passed, or have SELinux disabled.
@ford-prefect try with: sudo setenforce 0
Oh, indeed, that was it! Thank you both. Happy to dig further to see what we'd need to allow.
To clarify: The linux kernel usually reports SELinux denials via audit-messages. Furthermore, it returns EPERM
so user-space can deal with it. Unfortunately, this is NOT the case if SELinux denies transmission of a file-descriptor. Instead, it will simply drop the respective file-descriptor from the message with NO indication of doing so.
dbus-broker sees the message and notices a mismatch between the intended number of file-descriptors, and the actual number of file-descriptors, and it has no way to tell whether this is a fault of the client, or an LSM denial.
At some point the kernel should really fix this, but I am unaware of a backwards-compatible way to solve this. It will likely require some additional annotation somewhere in the ancillary data.
I will close this bug now. Feel free to re-open if you feel like there is more need for discussion!
This makes sense, thanks @dvdhrm!
This may or may not be an actual bug in
dbus-broker
, but any pointers to help debug this would be most appreciated.I have DBus method call that returns a file descriptor -- a socket corresponding to L2CAP LE connection-oriented channel (created with
socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP);
).If I try to put this fd in a message reply,
dbus-broker
silently terminates the connection (nothing is logged). If I replace this fd with something likeopen("/dev/null", O_RDONLY);
, the reply works correctly.