/tmp/printer permissions

[repetier]

I know klipper sets a link in /tmp/printer to /dev/pts/1 (normally). The problem is when /tmp has the sticky bit set (t as last permission) only root and user (pi in this case) can use the link.

Repetier-Server tries to use it as well but being run as repetierserver user it gets a permission denied.

If I remove the sticky bit with
sudo chmod -t /tmp
everything works fine. But reading about the sticky bit it is adviced to keep it for /tmp so unrelated software can not delete it - with mentioned side effect.

Can you add another link to the correct serial port that is useable for all users? I think for old users running e.g. octoprint as pi user it would be best to keep the old link for backward compatibility.

My suggestion is to create a folder /var/lib/Klipper during setup where all have access and where you add a copy of the link there as well. Might also be a better place for the log files especially if someone makes /tmp a ramdisk drive.

[klipper-gitissuebot]

Hi @repetier,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[repetier]

No log required here.

[KevinOConnor]

Thanks for the report. However, I'm not sure I understand the issue. The +t flag on a directory just prevents a user from deleting a file created by another user. It doesn't alter read permissions at all. The /tmp/printer file is just a link to the psuedo-terminal that Klipper uses to emulate a serial port - everyone can read the link (but typically only users in the "tty" group can read the actual pseudo terminal).

If some other user is trying to open /tmp/printer with open(..., O_CREAT) then that could prevent Klipper from being able to create the /tmp/printer file. However, if that's the case, I'd say it would be best to change that other program to not attempt to create /tmp/printer (that is, remove the O_CREAT flag from the open file request).

Let me know if I've missed something.

-Kevin

[repetier]

I know with earlier debian version I could read /tmp/printer so you could use it as device in Repetier-Server. At least with buster that does not work. It is not that I'm trying to delete it. Also I can use the /dev/pts/1 path to connect to klipper. But even testing if /tmp/printer exists in Repetier-Server can not stat the existence. It is very strange. To test I allowed repetierserver to login and test:

pi@Repetier-Server:~ $ sudo -u repetierserver ls /tmp/printer 
ls: cannot access '/tmp/printer': Permission denied
pi@Repetier-Server:~ $ sudo -u repetierserver ls -l /tmp/printer 
lrwxrwxrwx 1 pi pi 10 Aug 20 19:29 /tmp/printer -> /dev/pts/1

You see simple ls does not work ls -l does work. Same happens to software wanting to use it and not being user pi preventing it from using the link.

If I simply chmod /tmp to 777 removing the t flag the server can use the link without problems. Took me half a day to figure out that this was the problem.

Linux sets t flag after every reboot back. And as said it is normally a bad idea to remove it for several softwares that might use it. It is just a bad place to share data with other software. That is normally done in /var folder, hence my suggestion to add there at least a copy of the same link so other users can also use it.

Hope the problem is a bit more clear now. For now I have added a test in Repetier-Server 0.92.1 to not crash test function when permission is denied. You can test your self with that version if you like. You can install it in addition to octoprint, just do not connect on both the same time.

[KevinOConnor]

pi@Repetier-Server:~ $ sudo -u repetierserver ls /tmp/printer
ls: cannot access '/tmp/printer': Permission denied

ls is reporting that only because it can not follow the link (it doesn't have permission to read whatever the link points to). It can read the link itself - as indicated by your next line:

pi@Repetier-Server:~ $ sudo -u repetierserver ls -l /tmp/printer
lrwxrwxrwx 1 pi pi 10 Aug 20 19:29 /tmp/printer -> /dev/pts/1

The fix would be to ensure that the repetierserver user can access the tty (check the permissions of /dev , /dev/pts , and /dev/pts/1 ). Moving the location of the link itself wont change anything.

-Kevin

[repetier]

As I said using /dev/pts/1 directly is no problem and what users currently need to do to connect. That part has permissions set as needed.

But we use the C++ function to test if a file exists before starting a connection and that does not work on /tmp/printer for the same reason I guess that ls is failing in this case. So I can not check if /tmp/printer exists because i get permission denied and then we do not connect. And that is caused unfortunately by the t flag in /tmp permissions. A stupid side effect that makes no sense to me, but it exists.

That is why moving the link to a position with no t flag will help.

[KevinOConnor]

The main Klipper software can obtain the location of the pseudo-tty from the command-line. Specifically, one can add -I /path/to/something to the command-line args specified in /etc/default/klipper. There's a little bit of (somewhat related) documentation on this at https://www.klipper3d.org/FAQ.html#can-i-run-multiple-instances-of-klipper-on-the-same-host-machine .

I'm unable to reproduce the problem you describe. (FWIW, the +t flag is a well known Unix feature that only impacts the ability to delete a file - see man chmod for the details.) If one is using a C++ library to detect the existence of a file and that library is failing on files in a +t directory, then it sounds like a bug in that library.

-Kevin

[repetier]

Hi Kevin,
how did you test the issue? Did you run e.g. octoprint with a different user for testing? As I said the problem only exists if the using software is using a different user id like our server does.
It might a problem of gnu compiler since other software has the same problem under some circumstances like:

pi@Repetier-Server:~ $ sudo -u repetierserver ls /tmp/printer 
ls: cannot access '/tmp/printer': Permission denied

shows even default linux commands have trouble with that.

But ok, will add a FAQ entry for klipper and point them to the extra flag so they can choose a different folder and it will work in case it does not work for them as well. I know at least one other klipper user who pointed me to the problem.

BTW: My tests were on raspberry with debian buster latest version. Not sure if that is important as I know in the past /tmp/printer also worked for me. So meantime that must have changed somehow. Be it that older debian versions did not set +t or something else. I can not say.

[KevinOConnor]

I just ran unit tests. For example, as root:

mkdir /tmp/xyz
ln -s /root/.bashrc /tmp/xyz/testfile
ln -s /etc/motd /tmp/xyz/testfile2
chmod o+t /tmp/xyz

Then when run as a regular user I get:

$ ls -l /tmp/xyz/
total 0
lrwxrwxrwx 1 root root 13 Sep  6 10:49 testfile -> /root/.bashrc
lrwxrwxrwx 1 root root  9 Sep  6 10:50 testfile2 -> /etc/motd
$ ls /tmp/xyz/testfile
ls: cannot access '/tmp/xyz/testfile': Permission denied
$ ls /tmp/xyz/testfile2
/tmp/xyz/testfile2

However, I get identical results after running chmod o-t /tmp/xyz as root. So, I'm unable to reproduce any differences with +t.

-Kevin

[repetier]

Wrong test, you are not linking to a device. Try this instead:

sudo usermod -a -G tty games
pi@Repetier-Server:/var $ sudo chmod +t /tmp
pi@Repetier-Server:/var $ sudo -u games cat /tmp/printer 
cat: /tmp/printer: Permission denied
pi@Repetier-Server:/var $ sudo chmod -t /tmp
pi@Repetier-Server:/var $ sudo -u games cat /tmp/printer 
ok T0:24.2 /0.0
ok T0:24.3 /0.0

The temp responses are because server is also connected and polls temperatures. Adding tty to games is required as the device is owned by that group. That way you have same test as with repetier-server just on command line. You see with +t you cat permission denied while with -t cat can output responses.

[KevinOConnor]

Works fine for me:

pi@octopi:~ $ sudo usermod -a -G tty games
pi@octopi:~ $ ls -ld /tmp/
drwxrwxrwt 11 root root 4096 Sep 13 02:35 /tmp/
pi@octopi:~ $ sudo -u games cat /tmp/printer 
pi@octopi:~ $ sudo chmod +t /tmp
pi@octopi:~ $ sudo -u games cat /tmp/printer 
pi@octopi:~ $ 
pi@octopi:~ $ ls -l /tmp/printer 
lrwxrwxrwx 1 pi pi 10 Sep 13 02:32 /tmp/printer -> /dev/pts/2
pi@octopi:~ $ ls -lL /tmp/printer 
crw-rw---- 1 pi tty 136, 2 Sep 13 02:38 /tmp/printer

I'm not sure what problem you're running into, but what you're describing is not Unix behaviour. Maybe you've got a system with selinux enabled and it's just messing with you?

pi@octopi:~ $ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

-Kevin

EDIT:
Just for reference:

pi@octopi:~ $ sudo usermod -G games games
pi@octopi:~ $ groups games
games : games
pi@octopi:~ $ sudo -u games cat /tmp/printer 
cat: /tmp/printer: Permission denied

[repetier]

I see why you have no problems:-) As I said it used to work for me as well in the past. Our latest images are build on top of Debian Buster. So it is buster having changed the rules:-(
Can't say if they added selinux at the moment. All I did was upgrading the working image.

[technoplunk]

While I don't know the specifics of Debian Buster at the moment, Debian based systems don't usually have selinux (Redhat does) It's more common for Debian based systems to do additional restrictions with apparmor. Thus you might want to investigate that.

[repetier]

Also buster claims to have apparmour by default it is not installed in our image. So that is not the problem.

[SimoneBnc]

I am having the same issue with dietpi latest version that is running Buster while the previous install I had was using Stretch. I can connect to klipper only after running chmod -t /tmp

[TheBrigandier]

This issue (at least in my case, Raspbian Buster, with octoprint running as user octoprint, and klipper running as user klipper) is being caused by /proc/sys/fs/protected_symlinks being set to 1. Doing an echo 0 > /proc/sys/fs/protected_symlinks will turn it off temporarily if you'd like to test. It fixed the issue immediately for me. See: https://unix.stackexchange.com/questions/336625/symbolic-link-not-working-as-expected-when-changes-user

If you'd like to "fix" this through a reboot (not recommended, but may hold you over until this is fixed) add the following to the bottom of /etc/sysctl.conf:

# TEMP KLIPPER FIX
fs.protected_symlinks=0

Then run the command sysctl -p, no reboot required.

Easy fix may be relocating /tmp/printer to another place, since /tmp has sticky bit on by default (You can do this, I am blind, see my comments below). You probably don't want to remove sticky bit from it, it's there to keep users from smoking each other's files.

A notable bit of text from https://lore.kernel.org/patchwork/patch/311492/:

The solution is to permit symlinks to only be followed when outside a sticky world-writable directory, or when the uid of the symlink and follower match, or when the directory owner matches the symlink's owner.

So this will definitely bite anyone who's doing a good job of not running everything as root and running separate processes as completely separate users.

[SimoneBnc]

In fact I noticed that after reinstalling octoprint and klipper under the same user, the problem was gone

[KevinOConnor]

Thanks for reporting and tracking this down. It does seem that Klipper could do better here. Alas, changing the install scripts will cause lots of pain, so I don't have a timeframe for making a change.

-Kevin

[SimoneBnc]

Maybe just add a note in the install guide to suggest running klipper with the same user as octoprint. I had the issue with dietpi as by default it installs octoprint as root and I can't install klipper as root. Once I manually installed octoprint and klipper on on a normal user, my problem was solved.

[TheBrigandier]

I wouldn't suggest running as the same user. While it does make the issue go away, it's going to add installation complexity depending on the situation. While most users may be Klipper/Octoprint users, some may have special needs (i.e., using something besides Octoprint) and it kinda binds you at the hip to changes those apps make in the future. Users may have reasons or limitations (probably just elitists haha) for running things as separate users as well.

The true issue is that /tmp has sticky bit set, which causes the protected_symlinks bit to kick in. If you could relocate away from /tmp into a directory that doesn't have sticky bit (say, /opt/klipper/printer or some such, or even make this path user definable IT IS I AM BLIND, see my next comment), you solve this issue with very little change to installation and offer users the ability to set things up in any way they want.

[SimoneBnc]

Actually it makes sense since many distributions for Raspberry use a ramdrive for /tmp folder to avoid wearing the SD card with continuous log writing like for klippy.log

[repetier]

@SimoneBnc The problem also arises with Repetier-Server which runs as user repetierserver. Therefore my simple idea to add the /tmp link in a different directory like /var/lib/klipper as well. Would just be a few more lines in python code to add it there as well. Then users could select that link instead and have no problems.

As an intermediate solution I will remove the sticky bit in next server image release. But that only helps users using that image. Will also add the solution to remove that in our faq. But I do not see them as final solution as they all have a taste.

[SimoneBnc]

Still I don't see a problem running klipper as repetierserver user, maybe I'm missing something...

[repetier]

You are right running klipper with same user also works. But that is something no one thinks of when they follow the standard procedure.I add that as well as solution in my faq.

[SimoneBnc]

That's why I was suggesting to add it in the klipper install guide, as I stumbled upon this problem once I reinstalled the Raspberry with the buster release, while when it had stretch running I didn't have any problem

[TheBrigandier]

@KevinOConnor Just wanted to apologize for being completely blind. You mentioned the -I option (or --input-tty), but for some reason my brain / eyes filtered this out when initially scanning this ticket.

To everyone fighting with this, find where you are defining klippy.py's command line options and add --input-tty /your/preferred/path/to/printer. In my case the easiest fix was just to add /opt/klipper/ directory, give ownership of it to my klipper user and klipper group, and then add --input-tty /opt/klipper/printer to my Klipper startup script (I use a custom SystemD service for this, you may be using /etc/default/klipper). Octoprint is able to connect to it with zero issues as my /opt/klipper/ directory doesn't have the sticky bit.

[colinfindlay-nz]

Also for reference, anyone using udev rules to restart the firmware when the MCU is powered on will be encountering the same problem on Buster. (See #835 (comment))
Repointing away from /tmp/printer should resolve this.

[Nandox7]

@repetier did you end up removing it in the v20 image?
I just got bitten by this issue as well.

[repetier]

Yes I added the solution from @VileBrigandier so it is no issue in V20. That is all you really need.

[Nandox7]

Odd, I still had to edit sysctl.conf to make it work.
As it was still locking repetierserver user from accessing the /tmp/printer symlink.

[DanielJoyce]

The underlying issue is /tmp/printer or any link created by --input-tty points to /dev/pts-1 which has permissions of 0660, and user klipper, group tty.

Solution is to either create input tty in util.py with permission 0666 or add tty as a supplemental group to the octoprint user.

I think adding tty as a supplemental group might have security implications though.

[DanielJoyce]

Another option is to have klipper create the tty with a user-specifiable group, such as octoprint.

[ksalaba]

I had this issue with /tmp/printer except it was pointing to /dev/pts-2.

I resolved this issue by running chown on /tmp/ with my desired user. Probably overkill for what I needed. =/

I did reset it back to temp back to default using chmod 1777 /tmp
and changed the directory based on this comment #1902 (comment)

[mberlinger3]

I added my $USER (/tmp/printer owner) to the group octoprint and edited my octoprint.service to start as $USER. It defaults to octoprint as the user which cannot access the tmp files created by $USER.

Works fine on my manjaro install. You will have to set up octoprint again.

[dnasir]

Also for reference, anyone using udev rules to restart the firmware when the MCU is powered on will be encountering the same problem on Buster. (See #835 (comment))
Repointing away from /tmp/printer should resolve this.

Where should I point to instead?

[repetier]

Does not matter. Any directory you can read and write will work. It is just the special permission problem for /tmp preventing that this one works for different users.

[jccf07]

I had this issue with /tmp/printer except it was pointing to /dev/pts-2.

I resolved this issue by running chown on /tmp/ with my desired user. Probably overkill for what I needed. =/

I did reset it back to temp back to default using chmod 1777 /tmp and changed the directory based on this comment #1902 (comment)

It's works for me "sudo chown MyUser /tmp/printer" thanks!! ( I'm using Manjaro, arch Linux)

[jccf07]

I added my $USER (/tmp/printer owner) to the group octoprint and edited my octoprint.service to start as $USER. It defaults to octoprint as the user which cannot access the tmp files created by $USER.

Works fine on my manjaro install. You will have to set up octoprint again.

Hi! Could you please explain to me how to?? I have Manjaro but I don't know how to add MyUser to owner. Thanks

[mberlinger3]

I added my $USER (/tmp/printer owner) to the group octoprint and edited my octoprint.service to start as $USER. It defaults to octoprint as the user which cannot access the tmp files created by $USER.
Works fine on my manjaro install. You will have to set up octoprint again.

Hi! Could you please explain to me how to?? I have Manjaro but I don't know how to add MyUser to owner. Thanks

$ls -la /tmp/printer
record the owner and group

$systemctl edit --full octoprint.service
change the user to the previous one

[repetier]

Just as info for the near future. In the next repetier-server release 1.2.1 we will have a special klipper installer integrated. You can then install klipper in a working way directly from the server with correct user, even multiple and edit the printer settings directly in the server. At least on debian like distros where all packages required are available.

[rongith]

@repetier with the ~/printer_data/comms/klippy.serial is there still an issue? Or can it be closed?

[repetier]

This solves part of the problem (sticky bit in /tmp folder). Software not running as use pi can now be added to group tty to access serial. But there still is a problem with the api socket you create. It is only writeable by user pi preventing to be used by other users even if they are also in group pi. Permissions of upper folders could be changed manually, but socket gets recreated dynamically so would be good if klipper would chmod the permissions here. Hope this is easier to solve. Know several users struggling with that when using moonraker in parallel with Repetier-Server for example.

pi@RepetierServer:~/printer_data/comms $ ls -l
total 0
lrwxrwxrwx 1 pi pi 10 Oct  4 08:42 klippy.serial -> /dev/pts/2
srwxr-xr-x 1 pi pi  0 Oct  4 08:42 klippy.sock

[benecito]

I'm one of them. A simple change in webhooks.py solves the issue for us, but we need to apply it on every update.
I added
os.chmod(server_address,0o777)
after line 127 of webhooks.py