5 ms·

This is the first time I'm learning about DynamicUser, and I'd appreciate if someone check if the following line of thought is valid: • We have compute environ

This is the first time I'm learning about DynamicUser, and I'd appreciate if someone check if the following line of thought is valid: • We have compute environments that use a central LDAP service for end-user account info. End-user account info is served from LDAP, with `sssd` or `nslcd` being used on the systems (the only locally-defined accounts are system accounts and special admin accounts). • We do have accounts with UIDs in the range that systemd uses for the DynamicUser feature. • If systemd starts a DynamicUser service before the LDAP client (`sssd` et al) is up and running, it might allocate a UID that is in use by LDAP. • The systemd documentation does not specify if UIDs are chosen sequentially, at random, or via some other method. So, one must assume that any UID in the range—if (apparently) free—may be allocated. Does that thinking make sense? It seems like we will have a pretty big problem to deal with when we decide to move to a distro version which includes DynamicUser support (for example, Ubuntu 18.04). It also doesn't look like it's possible to set a custom range for DynamicUser UIDs.

leni536 8y ago
Looks like the range is compiled in. https://github.com/systemd/systemd/blob/5a8b16409240bc95d95f3c19d6f5cd9366e6ccf4/meson.build#L663 https://github.com/systemd/systemd/blob/5a8b16409240bc95d95f... https://github.com/systemd/systemd/blob/6f663594bc5ee087cb15175cb691eaebcc45a0a1/meson_options.txt#L159 https://github.com/systemd/systemd/blob/6f663594bc5ee087cb15... From the man page: > Dynamic users/groups are allocated from the UID/GID range 61184…65519. It is recommended to avoid this range for regular system or login users. It looks like you will have to compile systemd with a different range to behave well on your system. Edit: Apparently the UID allocation is randomish: https://github.com/systemd/systemd/blob/7426028b7a649bdfa4737fe4a355a6bd2e3d4543/src/core/dynamic-user.c#L187 https://github.com/systemd/systemd/blob/7426028b7a649bdfa473...
- AnIdiotOnTheNet 8y ago
  > Looks like the range is compiled in. Of course it is. UNIX devs...
  - zaarn 8y ago
    You should checkout suckless projects, they compile in everything. There is no config. Or rather, the #define statements are the config. I think the only time I legit used that is on an Arduino where both code and data have severe size limits.
    - qu4z-2 8y ago
      Alright, but they're designed for you to read through config.h (note that these settings aren't inlined) and adjust them for your system before building a binary. They're very explicitly not designed for a "grab your vendor binary and you'll be fine" model. It's a different paradigm. EDIT: The programs themselves are intended to be written in a programmer-modifiable way (they host a list of common "plugins" in patch format). I think the last thing you can say about systemd is that it encourages you to jump in and modify its behaviour to suit your needs. That's not a Supported Configuration(tm).
      - zaarn 8y ago
        >That's not a Supported Configuration(tm). Depends on what you modify but it's to my knowledge supported if your patches didn't cause the bug or behaviour problem. Plus there is plenty of ways to configure systemd at compile time, you can toggle a lot of switches in systemd.
  - jlv2 8y ago
    No, Linux devs...
    - jstanley 8y ago
      No, systemd devs...
      - danudey 8y ago
        qmail was written in the mid-90's, and all of the UIDs it would run as were compiled in. Meaning that if one of your mail users was UID 650 at compile time, the value of 650 would be compiled into the binary and it would always (and only) run that binary as that UID; if it didn't match up, it would fail. There were a lot of things about qmail that were outright stupid and awful, but not being able to port binaries between systems without a lot of checking was one of my favourites.
LukeShu 8y ago
leni536 is correct, the range is specified at compile time. https://github.com/systemd/systemd/blob/v239/doc/UIDS-GIDS.md https://github.com/systemd/systemd/blob/v239/doc/UIDS-GIDS.m... However, do note that if the service file sets a User= name, and that username already exists, then it will simply use that user, and disable DynamicUser for that service. All of the service files that ship with systemd itself set User=, making this possible for them, but 3rd-party service files might not. One thing you could look in to is writing a systemd generator (see the systemd.generator(7) man page) that injects User= in to DynamicUser=yes service files, and then ensures that local system users with each of those names exist.

leni536 8y ago

Looks like the range is compiled in. https://github.com/systemd/systemd/blob/5a8b16409240bc95d95f3c19d6f5cd9366e6ccf4/meson.build#L663 https://github.com/systemd/systemd/blob/5a8b16409240bc95d95f... https://github.com/systemd/systemd/blob/6f663594bc5ee087cb15175cb691eaebcc45a0a1/meson_options.txt#L159 https://github.com/systemd/systemd/blob/6f663594bc5ee087cb15... From the man page: > Dynamic users/groups are allocated from the UID/GID range 61184…65519. It is recommended to avoid this range for regular system or login users. It looks like you will have to compile systemd with a different range to behave well on your system. Edit: Apparently the UID allocation is randomish: https://github.com/systemd/systemd/blob/7426028b7a649bdfa4737fe4a355a6bd2e3d4543/src/core/dynamic-user.c#L187 https://github.com/systemd/systemd/blob/7426028b7a649bdfa473...

AnIdiotOnTheNet 8y ago
> Looks like the range is compiled in. Of course it is. UNIX devs...
- zaarn 8y ago
  You should checkout suckless projects, they compile in everything. There is no config. Or rather, the #define statements are the config. I think the only time I legit used that is on an Arduino where both code and data have severe size limits.
  - qu4z-2 8y ago
    Alright, but they're designed for you to read through config.h (note that these settings aren't inlined) and adjust them for your system before building a binary. They're very explicitly not designed for a "grab your vendor binary and you'll be fine" model. It's a different paradigm. EDIT: The programs themselves are intended to be written in a programmer-modifiable way (they host a list of common "plugins" in patch format). I think the last thing you can say about systemd is that it encourages you to jump in and modify its behaviour to suit your needs. That's not a Supported Configuration(tm).
    - zaarn 8y ago
      >That's not a Supported Configuration(tm). Depends on what you modify but it's to my knowledge supported if your patches didn't cause the bug or behaviour problem. Plus there is plenty of ways to configure systemd at compile time, you can toggle a lot of switches in systemd.
- jlv2 8y ago
  No, Linux devs...
  - jstanley 8y ago
    No, systemd devs...
    - danudey 8y ago
      qmail was written in the mid-90's, and all of the UIDs it would run as were compiled in. Meaning that if one of your mail users was UID 650 at compile time, the value of 650 would be compiled into the binary and it would always (and only) run that binary as that UID; if it didn't match up, it would fail. There were a lot of things about qmail that were outright stupid and awful, but not being able to port binaries between systems without a lot of checking was one of my favourites.

LukeShu 8y ago

leni536 is correct, the range is specified at compile time. https://github.com/systemd/systemd/blob/v239/doc/UIDS-GIDS.md https://github.com/systemd/systemd/blob/v239/doc/UIDS-GIDS.m... However, do note that if the service file sets a User= name, and that username already exists, then it will simply use that user, and disable DynamicUser for that service. All of the service files that ship with systemd itself set User=, making this possible for them, but 3rd-party service files might not. One thing you could look in to is writing a systemd generator (see the systemd.generator(7) man page) that injects User= in to DynamicUser=yes service files, and then ensures that local system users with each of those names exist.