Skip to content

Conversation

@MaKaNu
Copy link

@MaKaNu MaKaNu commented Apr 18, 2024

  • Add method isInElevatedGroup
  • check if the linux user is in plugdev
  • add logic for admin error check

Our users are always for root password. This is no Option.
We only use Cyton Dongle and this Improvment aims for Dongle usage.

To use Dongle under linux users must be in plugdev group.

- Add method isInElevatedGroup
- check if the linux user is in plugdev
- add logic for admin error check
@MaKaNu
Copy link
Author

MaKaNu commented Jan 5, 2025

Can I get some response to this PR?

Copy link
Member

@retiutut retiutut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello, work on GUI v7 has begun, and I would like to include this PR.

Let's keep this change isolated to only check on Linux and separated from other admin privileges checks.

*/
public boolean isInElevatedGroup() {
boolean result = true;
if (isLinux()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverse if and do if(!isLinux) return at the beginning of this method.


if (!isAdminUser() || isElevationNeeded()) {
outputError("OpenBCI_GUI: This application is not being run with Administrator access. This could limit the ability to connect to devices or read/write files.");
if (!isInElevatedGroup() && (!isAdminUser() || isElevationNeeded())) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please separate this out to new if statement and say if (isLinux() && !isInElevatedGroupLinux()) since this only applies to one OS.

*
* @return <code>true</code> if user is in group plugdev, <code>false</code> otherwise.
*/
public boolean isInElevatedGroup() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename isInElevatedGroupLinux()

@retiutut retiutut changed the title Feature improve error msg Fix detection of plugdev group for Linux users Mar 31, 2025
Copy link
Member

@retiutut retiutut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, can you please confirm this is a positive fix for all Linux users?

@MaKaNu
Copy link
Author

MaKaNu commented Apr 1, 2025

Also, can you please confirm this is a positive fix for all Linux users?

What do you mean by all Linux users? Do you talking about adding unit tests? If that's the case, I am wiling to contribute some as well, but I am not sure how to simulate/mock the scenario.

@retiutut
Copy link
Member

retiutut commented Apr 1, 2025

Also, can you please confirm this is a positive fix for all Linux users?

What do you mean by all Linux users? Do you talking about adding unit tests? If that's the case, I am wiling to contribute some as well, but I am not sure how to simulate/mock the scenario.

I mean all Linux users, not just for your use case.

@MaKaNu
Copy link
Author

MaKaNu commented Apr 2, 2025

I mean all Linux users, not just for your use case.

I just realized, that's mostly just a debian/ubuntu thing these days, to control usb access via static plugdev group. Further, it seems most other Distributions (Fedora, OpenSuse, Arch, even Gentoo) relay on udev and uaccess.

We also only tested for Cyton Biosensing Board Dongle, based on our availability.

In General, I would say yes, every Linux user is getting profit from changes in this area, since running GUI Applications in with sudo is in general a bad idea. Specific for us: We are dividing user and admin strictly on the systems, which makes sudo not accessible for the users.

An even better solution, would be proper packaging of the software, which also provide the specific udev rule with access to the usb dongle via uaccess.

@retiutut
Copy link
Member

retiutut commented Apr 2, 2025

So how does what you've described overlap/interact with an existing fix? Did you try the existing fix and it didn't work?

Found here: https://docs.openbci.com/Software/OpenBCISoftware/GUIDocs/#linux-users-serial-port-permissions

Side Note: We can realistically only target the most popular Linux distributions.

@MaKaNu
Copy link
Author

MaKaNu commented Apr 3, 2025

I just checked https://wiki.debian.org/SystemGroups And I can no longer remember, why we ended with the plugdev group. On the other Hand, the base of my MR is basic the reference of the fix you pointed against.

Side Note: We can realistically only target the most popular Linux distributions.

Absolutly. I was just surprised, that only debian based distributions are the only one which are focusing on the group approach to apply udev rules. The uaccess approach seems to be the new way and debian is just the last horse.

I see two solution for the MR:

  1. Implement it as the user information of https://docs.openbci.com/Software/OpenBCISoftware/GUIDocs/#linux-users-serial-port-permissions if the user is not dialup.
  2. Going the packaging (debian, redhat) way and providing specific udev rules for the devices.

Or a combination of both.

Or (don't prefered by me) close it and rely on the docs.

@retiutut
Copy link
Member

Moving forward on this ticket, it should be separated out for Linux users and not combined with the Windows methods. See existing feedback.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants