Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Serial] Open rfcomm device as unprivileged user #526
...if he has read and write access.
This requires the watcher to wait if the device is busy which means it's opened by root (or any other user) and typically happens if ModemManager is present and probes the new device. The same method is used for PPPSupport now which previously always waited for five seconds unconditionally. While that is unnessary if ModemManager is not present, it seems to be too short if it is.
I'm not 100 % sure about the 0.1 sec delay before checking the access permissions, but if I do it immediately after creating the device, R_OK and W_OK result in False (while E_OK works, so it's not that the file would be absent).
To avoid waiting perhaps use a GFile with a GFileMonitor.
I am thinking more in the below direction. Then store whether the user can read/write/whatever and update this as attributes change.
from gi.repository import Gio, GLib can_read_attr = Gio.FILE_ATTRIBUTE_ACCESS_CAN_READ def on_device_changed(mon, f, other_f, event): if event == Gio.FileMonitorEvent.ATTRIBUTE_CHANGED: print("Attribute changed") info = f.query_info(can_read_attr, Gio.FileQueryInfoFlags.NONE) can_read = info.get_attribute_boolean(can_read_attr) print(can_read) dev = Gio.File.new_for_path('/dev/kmem') monitor = dev.monitor(Gio.FileMonitorFlags.NONE) monitor.connect('changed', on_device_changed) loop = GLib.MainLoop() loop.run()
It's a udev rule that changes the group on my system:
We cannot wait for that to happen as such a rule might not be present.
Two schemes I could think of:
This is somewhat close to my solution with a timeout of 0.1 s.
That would be better in cases where udev is not involved or the user does not get access (he's not in the dialout group for my system) as we do not wait for the timeout, but it's a little messy otherwise.
Just half a year later
As a solution, I now check permissions once right after that's done. There might be a race condition where both the explicit check and a change event take place but I guess that's not too bad. The only issue I could think of is that we could start two user watchers for the same port.
Overall the current state works fine for me. I can connect to the serial service and get a root watcher that immediately gets replaced by a user watcher and can then connect to my test device (a Naze32) as if it would be connected via USB.
There's only one inconvenience: I have to disable ModemManager. If it probes the device no connection is possible afterward. I guess the commands it sends bring the Naze32 into some strange state so that the software cannot address it. That does not happen with USB but I guess that's just ModemManager checking on rfcomm devices but not ttyUSB, so there's little to nothing blueman could do about that.