sudoers file is not correct when username not default pi

[araemo]

This command in the sudoers file does not appear to be correct anymore.

I recently rebuilt my octopi since my old one was an out of date debian base. The new one is Raspbian 12, and when updating plugins in octoprint, it fails to restart. I tracked it to sudo prompting for password. It seems that octoprint now uses systemctl restart octoprint instead of some variant of /user/sbin/service. Once I changed my sudoers to allow my octoprint user to run systemctl restart octoprint without a password, octoprint was able to restart itself again.

OctoPi/src/modules/octopi/start_chroot_script

Line 211 in 0d4cd57

echo "${BASE_USER} ALL=NOPASSWD: /usr/sbin/service" > /etc/sudoers.d/octoprint-service

my new file is:

araemo ALL=NOPASSWD: /usr/bin/systemctl restart octoprint

[guysoft]

It looks like the issue is that the user "pi" can change now and that breaks it.

Searching online it looks like you can prefix the user id with a hash # like this:

 #1000    ALL=NOPASSWD: /usr/bin/systemctl restart octoprint

(source: https://www.sudo.ws/docs/man/1.8.17/sudoers.man/)

That should fix it, I need to test this.
@araemo if you feel like testing it like this it would speed up adding the fix

[b-morgan]

I believe the point here is that /usr/bin/service and /usr/bin/systemctl should both be allowed.

[guysoft]

@b-morgan OK right it does get updated here:
https://github.com/guysoft/OctoPi/blob/devel/src/modules/octopi/filesystem/home/root/bin/user-fix#L27

So why did it stop working is the next thing to ask

[araemo]

I want to be clear, I didn't have to change the username. It already had my username in that file. OctoPrint seems to handle that automatically:
https://github.com/OctoPrint/OctoPi-UpToDate/blob/58371593009e9001152adc952e0e451b1e2c63f2/scripts/files/user-fix#L34

allowing /usr/bin/service and /usr/bin/sytemctl would likely fix it. I don't know the logic behind which gets used in what scenario, just that my install of octoprint definitely uses systemctl to restart itself, not /usr/bin/service.

[araemo]

It looks like the issue is that the user "pi" can change now and that breaks it.

Searching online it looks like you can prefix the user id with a hash # like this:

 #1000    ALL=NOPASSWD: /usr/bin/systemctl restart octoprint

(source: https://www.sudo.ws/docs/man/1.8.17/sudoers.man/)

That should fix it, I need to test this. @araemo if you feel like testing it like this it would speed up adding the fix

This syntax seems to work as well.

[ngist]

I'm a bit confused as to why it's not just pi ALL = NOPASSWD : ALL in the sudoers file. If I setup ssh key access only in the pi imager, then I can happily ssh in to see whats wrong but I'm unable to fix anything because it keeps prompting me for a password that doesn't exist.

[araemo]

It looks like the issue is that the user "pi" can change now and that breaks it.

Searching online it looks like you can prefix the user id with a hash # like this:

 #1000    ALL=NOPASSWD: /usr/bin/systemctl restart octoprint

(source: https://www.sudo.ws/docs/man/1.8.17/sudoers.man/)

That should fix it, I need to test this. @araemo if you feel like testing it like this it would speed up adding the fix

Sorry for the delay here, I updated both files below to #1000 instead of a username, and I can still restart octoprint from the web UI.

/etc/sudoers.d/octoprint-service
/etc/sudoers.d/octoprint-shutdown

[verboEse]

I'm a bit confused as to why it's not just pi ALL = NOPASSWD : ALL in the sudoers file. If I setup ssh key access only in the pi imager, then I can happily ssh in to see whats wrong but I'm unable to fix anything because it keeps prompting me for a password that doesn't exist.

I'm struggling with the same problem: I'm not able to do a system maintenance (package upgrades etc.), as the base user has no password. Looks like trying to be more secure leads to being more vulnerable :-(