5

I have a 3D printer, with which my PC can communicate through /dev/ttyACM0:

crw-rw---- 1 root uucp 166,  0 16 nov 14:58 ttyACM0

The 3D printing application repetierHost requires read/write access to this device in order to function. If I 'naively' start the application without any preparation, the application doesn't work.

If I run the application as root, it works.

If I run the application as a normal user with (supplementary) group uucp, it still doesn't work.

If I give /dev/ttyACM0 the permission flags rw-rw-rw-, and run it with my normal user, it works.

(Why) does my permission through the uucp group not pass on to the application?

I would not be opposed to just giving the file rw-rw-rw- permissions, but these are reset when the device is disconnected and reconnected. If I can't make this work through theuucp group, how can I instead make the change to the permission flags persistent?

mhelvens
  • 263

2 Answers2

4

I would set the group of the repetierHost application to uucp and then set the SGID bit (as long as it is a real binary and not script):

chgrp uucp repetierHost
chmod g+s repetierHost

If the repetierHost is a script you could consider moving that to repetierHost.sh and write a small C programming wrapper repetierHost that calls repetierHost.sh

E.g.:

#include <stdlib.h>

int 
main(int argc, char *argv[])
{
    system("/path/to/repetierHost.sh");
}
Anthon
  • 79,293
  • I see. Are binary files treated as users like that? Will the new repetierHost binary that calls the old repetierHost script properly pass on the needed permissions? Isn't that the same situation as me calling the script manually (which didn't work)? – mhelvens Nov 16 '14 at 21:57
  • @mhelvens Yes if you have a binary that sets the GUID, than anything called by that keeps that group. I have used that for python and shell scripts. Updated the answer with an example – Anthon Nov 16 '14 at 22:16
  • Is there a reason you suggest a C program? Wouldn't it be simpler with a bash or Python script to call the .sh script? – A.L Nov 17 '14 at 01:09
  • @A.L If that would work, then why would you not just set the GUID bit on the original script? Check wikipedia Second paragraph, last sentence: Due to potential security issues,many operating systems ignore the setuid attribute when applied to executable shell scripts. (same holds for setgid) – Anthon Nov 17 '14 at 05:40
  • @Anthon: I tried this approach, and it doesn't seem to work. I can call the new C-sourced binary as a normal user, but the application still bails out with "Permission denied". However, I did find another solution that works, and I'm writing an answer for that. --- That said, I'm still curious about why it didn't work, and why you thought it would. – mhelvens Nov 17 '14 at 12:28
  • @mhelvens did you do the chmod g+s repetierHost on the binary executable? – Anthon Nov 17 '14 at 13:26
  • @Anthon: I did indeed. – mhelvens Nov 17 '14 at 13:46
  • @mhelvens Hmm, are you on Linux? Unix. What distro and version? – Anthon Nov 17 '14 at 13:53
  • @Anthon: Arch Linux, up to date with standard package trees. --- Do note that I tested this before Gilles (above) informed me that I had to log out and back in again for new groups to take effect. I'm guessing this doesn't apply to files, but... maybe it does? – mhelvens Nov 17 '14 at 16:36
1

I found the sg command, which seems to be exactly what I needed:

sg - execute command as different group ID

So I just write a minimal wrapper as follows:

#!/bin/bash
sg uucp /usr/bin/repetierHost.sh

This works perfectly.

mhelvens
  • 263
  • Though I admit I get more and more confused about this 'group' business. Why even make a distinction between primary and supplementary groups? Well, this is just a piece of Linux lore that I've yet to explore properly. – mhelvens Nov 17 '14 at 12:34