Unnecessarily permissive permission setup in instructions

[ndim]

I am not a user of octolapse, but I have been involved in the gphoto project on and off for almost 20 years, and have, in other projects, had a few bad experiences with security issues caused by, among other things, running processes as root via sudo just to give them access to a specific system resource.

A user of octolapse has pointed me to

https://github.com/FormerLurker/Octolapse/wiki/Configuring-an-External-Camera

which instructs people to add the following to their /etc/sudoers file:

# allow 'sudo gphoto2' to run without supplying a password
pi ALL = (root) NOPASSWD: /usr/bin/gphoto2

Given the size of the codebase gphoto2 involves, giving it blanket root access is a bad idea.

Those permissions are very likely granted just to give the gphoto2 process R/W access to the camera's device special file in /dev/bus/usb. You can achieve that R/W access in a much better (safer) way by just changing the permissions of the camera's device special file to allow the non-root user gphoto2 is running R/W access to the camera's device special file.

The basic mechanism to do that is called udev, the particular implementation of which nowadays is shipped as a part of systemd. You can define lists of devices by USB IDs or USB classes or simliar criteria, and directly change their permissions based upon that, or you can define those devices to belong to a local seat by tagging it with uaccess. Specific Linux distributions may do some things differently (from a technical or policy point of view), so I cannot tell you about the best way to do it on Raspberry Pi OS.

Anyway, please stop instructing people to run gphoto2 as root when there is a much safer alternative.

[FormerLurker]

I'll take a look at it. Keep in mind these instances of OctoPrint are meant to be local only (not available from the web in any way), though I get your point. I'm considering dropping support for DSLR anyway, since it generates a very large amount of support requests, and I don't have the necessary hardware to debug issues for specific cameras.

Those permissions are very likely granted just to give the gphoto2 process R/W access to the camera's device special file in /dev/bus/usb

I'm actually not sure why gphoto2 requires sudo in the first place. If I run commands from a terminal using the same user that runs the scripts from my plugin, sudo is not required. If I embed the calls in a script, sudo is required for whatever reason. Here's an example of a call from the terminal using the pi user:

 gphoto2 --capture-image-and-download --filename "/home/pi/scripts/test.jpg"

You've likely seen the script that runs this command in the guide you linked to. Running this same command in a .sh file requires sudo for the gphoto2 call (and ONLY the gphoto2 call), and I'm not sure why. I'm sure it's something simple, but I'm no linux expert.

If you are willing to make a contribution, I'd love to see some examples of setting up permissions properly for this use-case. I'm obviously not a linux expert, and it just happens to be the primary platform for Octoprint, which attracts a ton of users who've never used the OS before, so anything too technical will be avoided. I see SO many people that just embed the actual password within the script file because editing sudoers is too difficult to follow, so whatever instructions are posted need to be simple to follow, and nearly universal, or the guide should just be dropped completely if it is a security risk.

[FormerLurker]

OH, btw, I noticed you listed Stuttgart as your location. I have very fond memories of a year I spent there during college. Good times.

[ndim]

While one of my Raspberry Pis is running Raspberry Pi OS, I have no use case for either Octolapse or Octoprint, but I can still try to install Octolapse and diagnose what problem the sudo based instructions are trying to solve.

However, I definitively will not find the time to do that within the next few days. Please ping me if I have not posted any updates within three weeks.

[shintaroaibara]

While one of my Raspberry Pis is running Raspberry Pi OS, I have no use case for either Octolapse or Octoprint, but I can still try to install Octolapse and diagnose what problem the sudo based instructions are trying to solve.

However, I definitively will not find the time to do that within the next few days. Please ping me if I have not posted any updates within three weeks.

Ping :)

[FormerLurker]

Thank you for the reminder @shintaroaibara! I've been spread pretty thin lately, but trying to catch back up on a few of these. I have quite a backlog, and will attempt to knock as much as I can out ASAP.

[ndim]

You got me there. :-)

This is still on my TODO list. Thanks for the reminder.

[Xaldew]

I was setting up Octolapse today and this bugged me to the point where I dove in to try to fix it:

The problem doesn't seem to be related to USB permissions. Instead it seems like the problem is related to some kind of temporary file creation at the working directory of the script, which if I'm not mistaken, is simply the file system root (/) (Does gphoto2 create some temporary file to transfer the image?). Obviously, non-root users are not allowed to create files there so instead, we need to move:

cwd=$(pwd)
cd $SNAPSHOT_DIRECTORY
gphoto2 --auto-detect --capture-image-and-download --force-overwrite --filename "${SNAPSHOT_FULL_PATH}" 
cd $cwd 

Incidentally, this should also fix some knock-on effects from the root-permissions of the file, such as #756.