Weird user permission problem using client on Linux #159

Closed
jawi opened this Issue Mar 9, 2013 · 13 comments

Comments

Projects
None yet
4 participants
@jawi
Owner

jawi commented Mar 9, 2013

From #133 (comment):

It seems to be something else over here.
It seems to be a problem with the permissions to the device files, doesn't look like a Kernel issue.

I have a new machine, so I reinstalled KUbuntu and also the OlsClient from scratch.
In contrary to what I wrote earlier the Client does work for root, when I select the device ttyACM0 from the ComboBox or when I enter the original filename /dev/ttyACM0.

For normal users I get a No such port error (from the Client).
This is a bit strange because I belong to the group dialout so I should be able to open the device.

wayoda@shredder:~$ groups wayoda
wayoda : wayoda adm dialout cdrom sudo dip plugdev lpadmin sambashare
wayoda@shredder:~$ ll /dev/ttyACM0 
crw-rw---- 1 root dialout 166, 0 Jan 16 17:55 /dev/ttyACM0

When I do a

wayoda@shredder:~$ sudo chmod a+rw /dev/ttyACM0
wayoda@shredder:~$ ll /dev/ttyACM0 
crw-rw-rw- 1 root dialout 166, 0 Jan 16 18:03 /dev/ttyACM0

I can use the device as a normal user again.

But...

I used to point the OlsClient to a symlink to my device that I create with a simple udev rule

# The OpenLogicSniffer
SUBSYSTEM=="usb", ATTR{idVendor}=="04d8", ATTR{idProduct}=="fc92", MODE="0666", SYMLINK+="OLS"

setting the ComboBox to /dev/OLS would work.
This doesn't seem to work any more, not for normal user and not for root.

@wayoda

This comment has been minimized.

Show comment
Hide comment
@wayoda

wayoda Mar 11, 2013

I'm sorry,
I made a mistake in the udev rules file.

One of the weird features of udev rules is that ATTR and ATTRS are both valid keywords in rules-files with a sligthly different meaning.

When I use ATTRS instead of ATTR in the rules file...

# The OpenLogicSniffer
SUBSYSTEM=="usb", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fc92", MODE="0666", SYMLINK+="OLS"

... the OLS client accepts /dev/OLS as valid device and works for root. (The original problem that the client only works for root is still there)

But this issue here can be closed as invalid I think.

wayoda commented Mar 11, 2013

I'm sorry,
I made a mistake in the udev rules file.

One of the weird features of udev rules is that ATTR and ATTRS are both valid keywords in rules-files with a sligthly different meaning.

When I use ATTRS instead of ATTR in the rules file...

# The OpenLogicSniffer
SUBSYSTEM=="usb", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fc92", MODE="0666", SYMLINK+="OLS"

... the OLS client accepts /dev/OLS as valid device and works for root. (The original problem that the client only works for root is still there)

But this issue here can be closed as invalid I think.

@jawi

This comment has been minimized.

Show comment
Hide comment
@jawi

jawi Mar 11, 2013

Owner

Thanks for coming back on this.

I'll leave this issue open as to investigate the cause of the required root-permissions...

Owner

jawi commented Mar 11, 2013

Thanks for coming back on this.

I'll leave this issue open as to investigate the cause of the required root-permissions...

@stefanct

This comment has been minimized.

Show comment
Hide comment
@stefanct

stefanct Mar 12, 2013

Contributor

I am using this and it works for root and that username... usually.
ACTION=="add", SUBSYSTEMS=="tty", ENV{ID_MODEL}=="Logic_Sniffer_CDC-232", OWNER="<username>", SYMLINK="ttyOLS"

The interesting behavior starts when i reset the OLS while (non-root) capturing (to be more precise: while the clients waits while the trigger condition has not happened yet). After that it is no longer possible to access the OLS with the non-root user. Not even after resetting the OLS and restarting the client! I get the following when trying to fetch the metadata in the begin capturing dialog:

java.lang.IllegalStateException: JTermios call returned -1 at class purejavacomm.PureJavaSerialPort line 514
    at purejavacomm.PureJavaSerialPort.checkReturnCode(PureJavaSerialPort.java:1279)
    at purejavacomm.PureJavaSerialPort.setSerialPortParams(PureJavaSerialPort.java:514)
    at purejavacomm.PureJavaSerialPort.<init>(PureJavaSerialPort.java:1096)
    at purejavacomm.CommPortIdentifier.open(CommPortIdentifier.java:148)
    at nl.lxtreme.ols.io.serial.CommConnectionFactory.getSerialPort(CommConnectionFactory.java:141)
    at nl.lxtreme.ols.io.serial.CommConnectionFactory.obtainSerialPort(CommConnectionFactory.java:177)
    at nl.lxtreme.ols.io.serial.CommConnectionFactory.createConnection(CommConnectionFactory.java:72)
    at nl.lxtreme.ols.io.ConnectorServiceImpl.open(ConnectorServiceImpl.java:160)
    at org.sump.device.logicsniffer.LogicSnifferDevice.createStreamConnection(LogicSnifferDevice.java:159)
    at org.sump.device.logicsniffer.LogicSnifferDetectionTask.call(LogicSnifferDetectionTask.java:82)
    at org.sump.device.logicsniffer.LogicSnifferDeviceProfilePanel.obtainDeviceMetadata(LogicSnifferDeviceProfilePanel.java:353)
…

Most interestingly: when I launch the client as root afterwards and fetch the metadata once it starts working for the non-root user too! So it seems like the root access sanitizes some part of the stack again which does not work without root rights (bug in purejavacomm?). The behavior is not completely consistent and reproducible for me yet. I am using linux 3.8 ATM.

Contributor

stefanct commented Mar 12, 2013

I am using this and it works for root and that username... usually.
ACTION=="add", SUBSYSTEMS=="tty", ENV{ID_MODEL}=="Logic_Sniffer_CDC-232", OWNER="<username>", SYMLINK="ttyOLS"

The interesting behavior starts when i reset the OLS while (non-root) capturing (to be more precise: while the clients waits while the trigger condition has not happened yet). After that it is no longer possible to access the OLS with the non-root user. Not even after resetting the OLS and restarting the client! I get the following when trying to fetch the metadata in the begin capturing dialog:

java.lang.IllegalStateException: JTermios call returned -1 at class purejavacomm.PureJavaSerialPort line 514
    at purejavacomm.PureJavaSerialPort.checkReturnCode(PureJavaSerialPort.java:1279)
    at purejavacomm.PureJavaSerialPort.setSerialPortParams(PureJavaSerialPort.java:514)
    at purejavacomm.PureJavaSerialPort.<init>(PureJavaSerialPort.java:1096)
    at purejavacomm.CommPortIdentifier.open(CommPortIdentifier.java:148)
    at nl.lxtreme.ols.io.serial.CommConnectionFactory.getSerialPort(CommConnectionFactory.java:141)
    at nl.lxtreme.ols.io.serial.CommConnectionFactory.obtainSerialPort(CommConnectionFactory.java:177)
    at nl.lxtreme.ols.io.serial.CommConnectionFactory.createConnection(CommConnectionFactory.java:72)
    at nl.lxtreme.ols.io.ConnectorServiceImpl.open(ConnectorServiceImpl.java:160)
    at org.sump.device.logicsniffer.LogicSnifferDevice.createStreamConnection(LogicSnifferDevice.java:159)
    at org.sump.device.logicsniffer.LogicSnifferDetectionTask.call(LogicSnifferDetectionTask.java:82)
    at org.sump.device.logicsniffer.LogicSnifferDeviceProfilePanel.obtainDeviceMetadata(LogicSnifferDeviceProfilePanel.java:353)
…

Most interestingly: when I launch the client as root afterwards and fetch the metadata once it starts working for the non-root user too! So it seems like the root access sanitizes some part of the stack again which does not work without root rights (bug in purejavacomm?). The behavior is not completely consistent and reproducible for me yet. I am using linux 3.8 ATM.

@jawi

This comment has been minimized.

Show comment
Hide comment
@jawi

jawi Mar 13, 2013

Owner

@wayoda : the symlink that is created by your udev rule points to the direct USB-device, not the tty-device. I cannot open this device as normal user nor as root...

Owner

jawi commented Mar 13, 2013

@wayoda : the symlink that is created by your udev rule points to the direct USB-device, not the tty-device. I cannot open this device as normal user nor as root...

@jawi

This comment has been minimized.

Show comment
Hide comment
@jawi

jawi Mar 13, 2013

Owner

@stefanct : thanks for these details! This might be helpful during debugging...

Owner

jawi commented Mar 13, 2013

@stefanct : thanks for these details! This might be helpful during debugging...

@wayoda

This comment has been minimized.

Show comment
Hide comment
@wayoda

wayoda Mar 13, 2013

jawi wrote

@wayoda : the symlink that is created by your udev rule points to the direct USB-device,
not the tty-device. I cannot open this > device as normal user nor as root...

That is true for the the first (faulty) version of the udev rule using ATTR .

The corrected version
SUBSYSTEM=="usb", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fc92", MODE="0666", SYMLINK+="OLS"

using ATTRS points to the tty-devivce /dev/ttyACM0 (but only works for root)

stefanct's rule
ACTION=="add", SUBSYSTEMS=="tty", ENV{ID_MODEL}=="Logic_Sniffer_CDC-232", OWNER="<username>", SYMLINK="ttyOLS"

works only for root on my system:

uname -a Linux shredder 3.5.0-25-generic #39-Ubuntu SMP Mon Feb 25 18:26:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

wayoda commented Mar 13, 2013

jawi wrote

@wayoda : the symlink that is created by your udev rule points to the direct USB-device,
not the tty-device. I cannot open this > device as normal user nor as root...

That is true for the the first (faulty) version of the udev rule using ATTR .

The corrected version
SUBSYSTEM=="usb", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fc92", MODE="0666", SYMLINK+="OLS"

using ATTRS points to the tty-devivce /dev/ttyACM0 (but only works for root)

stefanct's rule
ACTION=="add", SUBSYSTEMS=="tty", ENV{ID_MODEL}=="Logic_Sniffer_CDC-232", OWNER="<username>", SYMLINK="ttyOLS"

works only for root on my system:

uname -a Linux shredder 3.5.0-25-generic #39-Ubuntu SMP Mon Feb 25 18:26:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

@stefanct

This comment has been minimized.

Show comment
Hide comment
@stefanct

stefanct May 10, 2013

Contributor

i have not investigated further, but i just found this purejavacomm issue fix which remotely looks interesting. nyholku/purejavacomm#10

also, with the current code (206d4fa) my workaround of running it as root does no long work because of a NPE:

    at org.sump.device.logicsniffer.profile.DeviceProfileManager.matches(DeviceProfileManager.java:204)
    at org.sump.device.logicsniffer.profile.DeviceProfileManager.findProfile(DeviceProfileManager.java:91)
    at org.sump.device.logicsniffer.LogicSnifferDetectionTask.getDeviceProfile(LogicSnifferDetectionTask.java:187)
    at org.sump.device.logicsniffer.LogicSnifferDetectionTask.call(LogicSnifferDetectionTask.java:119)
    at org.sump.device.logicsniffer.LogicSnifferDeviceProfilePanel.obtainDeviceMetadata(LogicSnifferDeviceProfilePanel.java:353)
    at org.sump.device.logicsniffer.LogicSnifferDeviceProfilePanel$ShowDeviceMetadataAction.actionPerformed(LogicSnifferDeviceProfilePanel.java:243)```
Contributor

stefanct commented May 10, 2013

i have not investigated further, but i just found this purejavacomm issue fix which remotely looks interesting. nyholku/purejavacomm#10

also, with the current code (206d4fa) my workaround of running it as root does no long work because of a NPE:

    at org.sump.device.logicsniffer.profile.DeviceProfileManager.matches(DeviceProfileManager.java:204)
    at org.sump.device.logicsniffer.profile.DeviceProfileManager.findProfile(DeviceProfileManager.java:91)
    at org.sump.device.logicsniffer.LogicSnifferDetectionTask.getDeviceProfile(LogicSnifferDetectionTask.java:187)
    at org.sump.device.logicsniffer.LogicSnifferDetectionTask.call(LogicSnifferDetectionTask.java:119)
    at org.sump.device.logicsniffer.LogicSnifferDeviceProfilePanel.obtainDeviceMetadata(LogicSnifferDeviceProfilePanel.java:353)
    at org.sump.device.logicsniffer.LogicSnifferDeviceProfilePanel$ShowDeviceMetadataAction.actionPerformed(LogicSnifferDeviceProfilePanel.java:243)```
@jawi

This comment has been minimized.

Show comment
Hide comment
@jawi

jawi May 12, 2013

Owner

@stefanct : it appears that your mentioned fix was already incorporated in an earlier release of PureJavaComm. Fortunately, there's a new version just released, which at least has fixed some of the issues on Linux. I want to give it a test-drive myself soon, in which I'll try to reproduce the behaviour of this issue again as well...

Owner

jawi commented May 12, 2013

@stefanct : it appears that your mentioned fix was already incorporated in an earlier release of PureJavaComm. Fortunately, there's a new version just released, which at least has fixed some of the issues on Linux. I want to give it a test-drive myself soon, in which I'll try to reproduce the behaviour of this issue again as well...

@stefanct

This comment has been minimized.

Show comment
Hide comment
@stefanct

stefanct May 12, 2013

Contributor

@jawi: when you push something related, let me know if/what I should test please

Contributor

stefanct commented May 12, 2013

@jawi: when you push something related, let me know if/what I should test please

@jawi

This comment has been minimized.

Show comment
Hide comment
@jawi

jawi Jun 22, 2013

Owner

@stefanct : the latest snapshots of 0.9.7 now include the latest version of PureJavacomm. If you like, you could give it a spin on Linux...

Owner

jawi commented Jun 22, 2013

@stefanct : the latest snapshots of 0.9.7 now include the latest version of PureJavacomm. If you like, you could give it a spin on Linux...

@tom4tom

This comment has been minimized.

Show comment
Hide comment
@tom4tom

tom4tom Jul 10, 2013

Same Prob. on a new installed Ubuntu 12.04!
I build your latest 0.9.7 snapshot, and with a normal User and this permissions it works ;-)


$ ll /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Jul 10 21:51 /dev/ttyACM0


Seems that latest version of PureJavacomm helps...

Many Thanks, ToM

tom4tom commented Jul 10, 2013

Same Prob. on a new installed Ubuntu 12.04!
I build your latest 0.9.7 snapshot, and with a normal User and this permissions it works ;-)


$ ll /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Jul 10 21:51 /dev/ttyACM0


Seems that latest version of PureJavacomm helps...

Many Thanks, ToM

@jawi

This comment has been minimized.

Show comment
Hide comment
@jawi

jawi Jul 12, 2013

Owner

@tom4tom : thanks for reporting this back; glad to hear it is working for you now...

Owner

jawi commented Jul 12, 2013

@tom4tom : thanks for reporting this back; glad to hear it is working for you now...

@jawi

This comment has been minimized.

Show comment
Hide comment
@jawi

jawi Aug 12, 2013

Owner

Tested upcoming 0.9.7 with Linux Mint 15, and verified that after adding a non-root user to the proper group (i.e. dialout) the OLS client can use the serial port normally.

Owner

jawi commented Aug 12, 2013

Tested upcoming 0.9.7 with Linux Mint 15, and verified that after adding a non-root user to the proper group (i.e. dialout) the OLS client can use the serial port normally.

@jawi jawi closed this Aug 12, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment