Multi-User: Howto/BestPractice for App packaging

Applications
#1

Hi,

I have a package where I need, at compile time, to specify a UNIX group.
This group is used to set an executable SETGID, with the purpose to limit who can execute it.

I would like the “default user” / System Admin to be the one to be able to execute this.

Now, at the moment we have three kinds of devices:

  1. SFOS < 3.4: Only relevant user is nemo:nemo
  2. SFOS >= 3.4, flashed: admin user is defaultuser:defaultuser
  3. SFOS >=3.4, OTA updated: user is still nemo:nemo

My concrete questions:

  • which group would be best to use for representing this is the admin user so I can SETGID my binary
  • how do I get my .spec file to build versions which will be correct for each of the cases?
  • how correctly migrate old permissions/group ownership in the RPM upgrade case?
#2

Best practice tip:
You should NEVER install package files to /home

1 Like
#3

Agreed, and I shall update whatever apps I have to follow this soon where necessary.

In my original question though, home doesn’t enter the picture

#4

what is your question about then? why you bother usernames?

1 Like
#5

I would like to know, which group, not user, name to use to represent “admin user”.

This can either be nemo or defaultuser depending on device history. I know of no way to create a .spec/.rpm file which will handle either case.
Best would be to have a third one which will have those semantics, but a stable name (ssu maybe?).

I can of course add my own custom group for this, but I’d like to avoid that, it’s bound to be trouble at some point.

#6

still can’t understand why you want to know username to operate in spec file. what is the use-case?

#7

Again, I don’t want to know the user name.

I want to know a UNIX group name the members of which are considered “admin” users in the SailfishOS sense, (but not root).

This group name is used to install the binary setGID, so only members of this group can execute it.

#8

why you want to do that?

#9

@nephros, you can determine the name or group of the “primary user” (IIRC that is Jolla’s term) by determining who is logged in at “seat0” per loginctl. See e.g., Jolla’s udisksctl-user script (in SailfishOS since v3.2.0, IIRC).

But as @coderus already pointed out, very likely there is something structurally wrong if any information about interactive users (name, group, homedir etc.) is used in a spec file.

1 Like
#10

Thank you both for replying.

The application I am packaging is mlocate (an implementation of the Unix locate program).
As you probably know, this is used to find (locate :wink: ) files on the filesystem in a quick way.

This application has two components:

  • One that runs regularly as root (so it has access to all files), and collects file names in a database file.
  • A second one, the userfacing binary, which reads that database and matches a parameter the user gives it.

Now, as there is a security issue with any user having access to those filenames stored in the database (after all, any user should not just be able to learn about any filenames of another user), the security mechanism used is that the database is stored with these permissions:

-rw-r----- 1 root locate 39663589 Nov 11 03:27 /var/lib/mlocate/mlocate.db

The locate binary then is installed with these:

-rwx--s--- 1 root locate 38448 Mar  6  2019 /usr/bin/locate

So this way, only users in the locate group can execute and therefore read the filename database.

In the upstream implementation (see here for the source) this group name is given at compile time (and compiled into the binary through config.h), and in the case of an spec/rpm packaging, again in the %install and %files macros.

Now with SFOS, that didn’t use to be a problem, I just use the nemo group instead of locate and everything is fine. Now with the situation in 3.4 multi-user, things aren’t as easy any more. I can not hardcode a group name anymore in the call to configure or make. It can either be defaultuser or nemo depending on the installing device.

So either I have to do two separate builds, in which case I have to have a way to encode into the RPM which is the correct one for pkcon/zypper to select. Or I ship an RPM with both binaries and handle the wrong one in a post script. Neither is very good.

I can also, like most regular Linux distributions do, create a new Unix group on the installing system. I also would like to avoid that if possible.

The best way would be if there was a defined UNIX group that is neither nemo nor defaultuser, but a third one that is stable among all devices, but secondary users will never be in that group. Hence my question.

#11

if you was ok to make it nemo-accessible, then it means you don’t really need any security here. Or i just can’t understand for what you want to restrict the acces?

Also, you can utilize special privileged group. It was designed to restrict regular (nemo) user to access runtime system configuration stored in home directory. But as well as with other “security” nothing can stop random app to gain these “privileges” by installing special bits.

1 Like
#12

You are right of course that there isn’t really a critical security issue there.

Still, I want to follow “upstream” ideas as much as possible as a rule.
On the one hand that means for SFOS, recognizing that the defaultuser is somewhat special, and all other users are expected to be restricted in their access.
On the other hand to follow the way mlocate is designed/expected/supposed to work, and that is through that setgid group idea.

And also, to maybe learn how others deal with the multiuser situation in their apps, using my problem as an example more or less.

#13

Do you plan to include any user-interactive application? Then you can restrict db later, when user open app for the first time.

#14

Not planned by me no. The db could be used by a UI app though in theory, which wraps whatever locate is doing.

But the db is created (if it does not exist) not by the package but by a systemd timer (which runs the updatedb process which actually creates it, and sets permissions and ownerships according to compile-time configuration).

EDIT: However, there is gmLocate by sh6668 which uses the tool/database.

#15

Maybe you should let the users to configure that manually and install it as readable for all users. Just plaster warning on download page and show commands how to secure it.

1 Like
#16

Sure you can by using one of the existing (i.e., predefined) groups, which contains the primary user as a member.
The group sailfish-system may be a good choice; it is defined and contains the user nemo since some SailfishOS version between 3.0.0 and before 3.2.0 3.3 or 3.4.

2 Likes
#17

Still on 3.2.1.20 here and I do not have ‘sailfish-system’ but only ‘system’ as group?
Maybe it came later (with defaultuser?)?

1 Like
#18

Oh sorry, “it is defined and contains the user nemo since some SailfishOS version between 3.0.0 and before 3.2.0” applies to the group media_rw; sailfish-system replacing the group system happened later (with 3.3 or 3.4).

1 Like
#19

Re-reading the Multi-User Support Blog post led me to find this.

Apparently one can (and should?) create custom groups from RPM post scripts using sailfish-setup.

I shall experiment with that, looks like that would be a convenient solution.

[EDIT:] well, looks like productive SFOS does not install that script, so that proposed solution can not be used at the moment… :confused:

1 Like