Problem adding a directory user as local copy (user|group ... already exists)

[sjvudp]

With systemd there are a bunch of new problems, for example the tempfiles mechanism that creates all temporary directories early during boot. I you get your users and/or groups from a network service (NIS, LDAP, AD, SSS), systemd does not find these users as the network is not up when tempfiles are created, causing a boot failure (more or less).

So my workaround was to write a tool that can create selective users and groups identically to what is found in the LDAP database.

Unfortunately the {user,group}{add,mod,del} utilities do not allow me to create a local user when a user with the same name already exists in LDAP. Option "-o" also does not help here.

So I'm suggesting an option that will allow creation of local users and groups, even if a user/group with the same name already exists in a directory service like LDAP, NIS, etc. Without such an option, the only way to get the job done is using an editor on /etc/passwd and /etc/groups as I did 25 years ago... Of course the manual page could document for this new option with a warning "Be sure you know what you are doing".

[sjvudp]

Looking into the sources, I found this code in check_flags() of groupadd.c:

    /* local, no need for xgetgrnam */
    if (prefix_getgrnam (group_name) != NULL) {
        /* The group already exist */
        if (fflg) {
            /* OK, no need to do anything */
            exit (E_SUCCESS);
        }
        fprintf (stderr,
                 _("%s: group '%s' already exists\n"),
                 Prog, group_name);
        exit (E_NAME_IN_USE);
    }

Looking at prefix_getgrnam()'s definition in prefix_flag.c, I see that prefix_getgrnam() seems to consider the local file if group_db_file is set; if unset it uses the normal getgrnam(name), controlled by /etc/nsswitch.conf or similar.

My version of shadow tools showing the bug is older than above source, and maybe vendor-hacked (SLES12 SP4).

[hallyn]

Would the right solution be for systemd to ship a pam file which ensures that, on login by a non-local user, those actions (creating tmpfile dirs etc) are done?

[sjvudp]

Serge Hallyn notifications@github.com schrieb am 16.07.2019 um 00:35 in Nachricht shadow-maint/shadow/issues/169/511595025@github.com: Would the right solution be for systemd to ship a pam file which ensures that, on login by a non-local user, those actions (creating tmpfile dirs etc) are done?

Probably, but why isn't here an option to create a local user if a remote (directory) user with the same name and/or UID exists? Having to use a text editor to do the changes doesn't look like the correct solution.

[hallyn]

Serge Hallyn @.***> schrieb am 16.07.2019 um 00:35 in Nachricht shadow-maint/shadow/issues/169/511595025@github.com: Would the right solution be for systemd to ship a pam file which ensures that, on login by a non-local user, those actions (creating tmpfile dirs etc) are done? Probably, but why isn't here an option to create a local user if a remote (directory) user with the same name and/or UID exists? Having to use a text editor to do the changes doesn't look like the correct solution.

What exactly should the user creation in that case mean? Presumably you'd want the authentication to continue to be against the remote db? Exactly which steps are you currently doing manually to "locally create" the user ?

[sjvudp]

I don't quite understand the question: useradd and groupadd only can add to local files AFAIK, so the question against which DB to authenticate is irrelevant: It's not a case for useradd to deal with, but maybe nsswitch services or sssd. Also, as said before, to add a user/group locally when useradd/groupadd fails, I'll have to use a text editor, vipw, maybe.

[glensc]

I think @hallyn described solution creating the local users via pam mechanism.

[sjvudp]

The problem I'm trying to fix happens very early before a use logs in. Despite of that the user in question never logs in: A service is running with that account.

I can agree that I can (try to) create runtime directories every time a service starts, but that's quite some ugly solution compared to adding a switch allowing to create a local user forcibly.

[hallyn]

"before a user logs in" -> valid objection.

Would you care to propose a PR for this?

[sjvudp]

Would you care to propose a PR for this?

I'm afraid I don't understand (assuming "PR" means "problem report"): Isn't this a "PR"?

[glensc]

PR is Pull Request in GitHub terms: https://help.github.com/en/articles/about-pull-requests

[hallyn]

@sjvudp If you have a patch for this, I'm happy to take a look.