Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make the device files be owned by the group 'plugdev' #3

Closed
wants to merge 1 commit into from

Conversation

PoroCYon
Copy link

By default on my machine (Void Linux), the device files are owned by root:root. With the GROUP="0660" statement, this doesn't really help much. Instead, the files need to be root:plugdev in order for eg. FIDO2 support to work correctly.

By default on my machine (Void Linux), the device files are owned by
root:root. With the GROUP="0660" statement, this doesn't really help
much. Instead, the files need to be root:plugdev in order for eg. FIDO2
support to work correctly.
@bobsaintcool
Copy link
Collaborator

Hello @PoroCYon is you setup using systemd + systemd-logind? The purpose of using mode of 0660 and the device owned by 0:0 is to benefit from the uaccess tag that is integrated with systemd. Thus it will provide logged user access to the device using ACL.

If you system does not support systemd for some reason, I believe this modification should ever be made at your distribution level because systemd is now part of the default Linux distribution ecosystem. With this in ligth I'm not sure this change should be present in this file. However you contribution should be backported into the documentation/wiki

@PoroCYon
Copy link
Author

PoroCYon commented Nov 26, 2022

Yeah, Void Linux uses runit instead of systemd. (I packaged it myself as there are no official packages.)

@bobsaintcool
Copy link
Collaborator

This is nice you troubleshooting all the way up to find a working solution.

As Void Linux is not using systemd I'll suggest to convert this PR that change the existing rule to a PR that add documentation about the work you did to find the fix. In addition, I believe that such change should be at the distribution level and that the diff generated by your original commit should be applied from your personal recipe to build the package on your side.
It could be nice that this build recipe being public and that information available on the documentation of the project.

What do you think?

@PoroCYon
Copy link
Author

I can change it to add documentation, sure, but where should that documentation be? Just here in the README.md file?

I'm planning on upstreaming my package templates, but that's something for Later™. (I'd also have to find a few other people to test them for me.)

@bobsaintcool
Copy link
Collaborator

I'll say adding a section on the moolticute documentation can be nice for "Linux without systemd". You can start by speaking about the plugdev group there before publishing your recipe when you are ready.

DId you also consider talking to the dude other IRC to see if other are experimenting the same issue as you?

@PoroCYon
Copy link
Author

What exactly would "the moolticute documentation" be? The README.md file of this repo? (Both its wiki and its documentation folder are rather empty...) The user manual PDF?

I didn't yet ask on IRC because I already know that half of the people there don't run Void, but I just sent a message earlier to see if I'm lucky.

@bobsaintcool
Copy link
Collaborator

bobsaintcool commented Nov 29, 2022

I was considering directly into the Readme but I have no strong opinion on this. This is just where things seems to be, but I didn't get a closer look at the user manual lately, this could be a great idea as well.

I've introduced a draft PR for my idea, feel free to complete, I've not done any test so far, just some tips to get you started
mooltipass/moolticute#1094

@bobsaintcool
Copy link
Collaborator

@PoroCYon feel free to contribute there ;)

@bobsaintcool
Copy link
Collaborator

I will consider that mooltipass/moolticute#1094 is enough. I'll let you open a new PR if you believe we can move forward later

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.

3 participants