Is your feature improvement request related to a problem? Please describe.
Allow users to run tedge connect c8y as a non-root user, and without relying on hardcoded user/groups "tedge" and "mosquitto".
Though other commands like tedge init allow the user to specify the user/group to be used, e.g.:
tedge init --user peter --group staff
Concrete example: running mosquitto and tedge-agent under users account
If a user is running mosquitto as a service running under the current users (e.g. peter). This means that the mosquitto user does not exist (and neither does tedge).
When executing tedge connect c8y it will panic when the mosquitto user does not exist as tries to change the ownership of the device certificate files as it assumes that the mosquitto service won't be able to access them (which isn't the case as mosquitto is running as the current user and not under mosquitto).
tedge connect c8y
Detected mosquitto version >= 2.0.0
Checking if homebrew is available.
Checking if configuration for requested bridge already exists.
Validating the bridge certificates.
Creating the device in Cumulocity cloud.
Saving configuration for requested bridge.
Restarting mosquitto service.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: UserNotFound { user: "mosquitto" }', crates/core/tedge/src/cli/connect/command.rs:568:78
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
The code even includes a command about possible ignore errors.
Describe the solution you'd like
There are a few different options how this problem could be solved and each one should be evaluated to select the best one.
Option 1: Don't fail when trying to change ownership of cert files
Try change the file ownership of the device certificate files, but ignore any errors (and only log the errors on the INFO level).
A slight variant on this would be to not even attempt to change the file ownership unless you are running as root (as any other attempt change ownership will likely fail).
Option 2: Allow users to configure which user own the device certificates
Add new tedge config settings to control which user/group should be the owner of the device certificate files. This would allow the user to control the ownership.
Option 3: tedge connect should not try changing ownership of the device certificates
Don't try and change the ownership of the device certificate files when running tedge connect. Instead let the user control the certificate ownership during the tedge cert create step by supporting two new flags, --user <USER> and --group <GROUP> (following the same flag names used by the tedge init command).
The risk here would be if the user created certificates with the incorrect permissions, then the tedge connect would not be able to fix the file permissions which could lead to the certificates not being able to be read by mosquitto.
Describe alternatives you've considered
Additional context
The situation was discovered whilst trying to install thin-edge.io on MacOS using homebrew. mosquitto can be installed using homebrew, and it does not create a user called "mosquitto" as the mosquitto service is run under the current user's account (as this does not require any root permissions).
Below shows the mosquitto and tedge-agent services running as the current user peter.
$ brew services list
Name Status User File
mosquitto started peter ~/Library/LaunchAgents/homebrew.mxcl.mosquitto.plist
tedge-agent started peter ~/Library/LaunchAgents/tedge-agent.plist
And the certificates shows that they are owned by the current user peter and therefore would also be accessible by the mosquitto service as it is also running under the current user's account (peter).
$ whoami
peter
$ ls -l /opt/homebrew/etc/tedge/device-certs/
total 16
-r--r--r-- 1 peter admin 648 May 9 16:20 tedge-certificate.pem
-r-------- 1 peter admin 241 May 9 16:20 tedge-private-key.pem
Is your feature improvement request related to a problem? Please describe.
Allow users to run
tedge connect c8yas a non-root user, and without relying on hardcoded user/groups "tedge" and "mosquitto".Though other commands like
tedge initallow the user to specify the user/group to be used, e.g.:Concrete example: running mosquitto and tedge-agent under users account
If a user is running mosquitto as a service running under the current users (e.g.
peter). This means that themosquittouser does not exist (and neither doestedge).When executing
tedge connect c8yit will panic when themosquittouser does not exist as tries to change the ownership of the device certificate files as it assumes that the mosquitto service won't be able to access them (which isn't the case as mosquitto is running as the current user and not undermosquitto).The code mentioned in the panic is shown below:
// Ignore errors - This was the behavior with the now deprecated user manager.
The code even includes a command about possible ignore errors.
Describe the solution you'd like
There are a few different options how this problem could be solved and each one should be evaluated to select the best one.
Option 1: Don't fail when trying to change ownership of cert files
Try change the file ownership of the device certificate files, but ignore any errors (and only log the errors on the INFO level).
A slight variant on this would be to not even attempt to change the file ownership unless you are running as root (as any other attempt change ownership will likely fail).
Option 2: Allow users to configure which user own the device certificates
Add new tedge config settings to control which user/group should be the owner of the device certificate files. This would allow the user to control the ownership.
Option 3: tedge connect should not try changing ownership of the device certificates
Don't try and change the ownership of the device certificate files when running
tedge connect. Instead let the user control the certificate ownership during thetedge cert createstep by supporting two new flags,--user <USER>and--group <GROUP>(following the same flag names used by thetedge initcommand).The risk here would be if the user created certificates with the incorrect permissions, then the
tedge connectwould not be able to fix the file permissions which could lead to the certificates not being able to be read by mosquitto.Describe alternatives you've considered
Additional context
The situation was discovered whilst trying to install thin-edge.io on MacOS using homebrew. mosquitto can be installed using homebrew, and it does not create a user called "mosquitto" as the mosquitto service is run under the current user's account (as this does not require any root permissions).
Below shows the mosquitto and tedge-agent services running as the current user
peter.And the certificates shows that they are owned by the current user
peterand therefore would also be accessible by the mosquitto service as it is also running under the current user's account (peter).