0

I am working with a Linux embedded system. It has a special account that is used to run software compiled by the manufacturer's programming environment. This account purposefully has the login disabled. The account has all the permissions and belongs to the groups it needs for the installed software to work. The installed software resides in a sub directory of the user account and the system knows to run such and such a program in such and such a directory after booting.

So let us say we deploy this thing to the 'field' where linux admins are scarce. We don't want to give field techs root passwords.

How would they install an update to the software?

An update comes in the form of a binary file. In a developer setting, you can simply overwrite the old binary with a new one and then reboot. But developers have the root password on developer systems.

8
  • Are they network connected? Do they have USB ports or SD/MMC card slots? How did you plan to get the software onto the device in the first place? Apr 3, 2019 at 0:47
  • The devices are network connected. They also have a USB interface that can be used to mount a filesystem. We usually move installation files by network.
    – jeffry7
    Apr 3, 2019 at 13:11
  • Just automate it, then, so field techs don't have to do anything but plug in a USB stick, or nothing at all because you've pushed the update over the network. Apr 3, 2019 at 14:17
  • @MichaelHampton, Automate what though? For a network install, a non root user will copy the binary over and then must somehow place the file in the correct directory with the correct permissions.
    – jeffry7
    Apr 3, 2019 at 15:27
  • Why do you need a user to do anything? Apr 3, 2019 at 15:32

2 Answers 2

1

I would think about following options:

  • sudo

You can have some operator user with limited permission but with permission to sudo ("run as"). So this operator user can login with own credentials / ssh key and do the job. You can also limit the permission on sudo (sudoers) level and / or in case of ssh key on ssh level - you can limit session just for some command in case of use specific key for ssh login.

  • setuid bit

In case you can prepare the binary file doing the update (script files is often not accepted for this approach for the security reason) you can set the file with ownership of the "special account" and proper bit (e.g. using chmod) to be run by other user (may be regular user in case the execute permission is granted) but it is executed as it would be run by the owner even it is not the account which is executing the file.

chmod 4755 <file>

This will set (in order):

  • 4 ... setuid bit

  • 7 ... read & write & execute for owner

  • 5 ... read & execute for (owner's) group

  • 5 ... read & execute for other

Once "other" (let say operational account - for update) run the file it will be executed as it would be run as owner (application user). The file can be e.g. update_binary.


operator@box$ ls -la

-rwsr-xr-x 1 technician ... update_binary

Once the file will be executed by operator (without any additional requirements) it will be run anyway as technician

operator@box$ ./update_binary <parameters>

The process and any filesystem operation will be realized as user technician.

-- edit : use the same terminology - operator : user who make the changes / technician : technical user on the box for the app ---

0

Your binary:

ls -ld /home/app/subdir/a.out     # -rwxr-x--- app app  (example)

Add user technician to group app:

usermod -a -G app technician  

Let the entire group modify the binary:

chmod g+rwx a.out     # makes it -rwxrwx---

Let the entire group access the binary through the directory within its path (the x for directory):

chmod g+x  /home/app/subdir
chmod g+x  /home/app
# repeat for each subdirectory of the path, if owned by app:app

Try - login as the technician

cat new.binary > /home/app/subdir/a.out

(This doesn't allow you to move or remove the a.out file, only to write to it. These are the operations on the directory, not on the file, so you'd need to chmod g+rwx /home/app/subdir instead)

3
  • su - technician expect to be run as root or with knowledge of the password of the "technician" user. sudo may be the most probably more suitable as it can operate with "operator" own password.
    – Kamil J
    Apr 2, 2019 at 22:21
  • @KamilJ As a dev, they try it out with a root password. As a technician in the field, they are already there, so no need to su/sudo.
    – kubanczyk
    Apr 2, 2019 at 22:24
  • In case there is the same group ownership for all files which would be replaced and there is not any other specific need to use groups (group ownership & permissions) this approach would work ;-).
    – Kamil J
    Apr 2, 2019 at 22:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .