found a unowned directory "accountsservice"

sjensen · 2018-10-13 19:09:39

Hi,...

while I was trying to examine, why the "git" user is not marked as a system user and displayed in gnome-control-center, I found a "unowned" directory:

$tree /var/lib/accountsservice/

/var/lib/accountsservice/
├── icons
└── users
    ├── gdm
    └── sjensen

2 directories, 2 files

$tree /var/lib/AccountsService/

/var/lib/AccountsService/
├── icons
└── users
    ├── gdm
    └── sjensen

2 directories, 2 files

$LANG=C pacman -Qo /var/lib/accountsservice/

error: No package owns /var/lib/accountsservice

$LANG=C pacman -Qo /var/lib/AccountsService/

/var/lib/AccountsService/ is owned by accountsservice 0.6.54-1

Is it save to delete the unowned "accountsservice"? Where did it come from anyway?

I also get a lot of messages relating to "Accountsservice" lately, but maybe this has nothing to do with it:

$LANG=C gnome-control-center user-accounts

(gnome-control-center:18396): accountsservice-WARNING **: 20:42:57.483: Could not get current seat: No data available

Why are there 2 directories for the Accountsservice. Is one from an old package or is it a bug in a current package?

$ls -l /var/lib/ | grep -i account

drwxr-xr-x  4 root         root                4096 27. Sep 09:46 accountsservice
drwxr-xr-x  4 root         root                4096  6. Mär 2016  AccountsService

The "unowned" dir is younger, but I have not messed with the AccountsService till yesterday. I am pretty sure I did not created it by ~~incident~~ accident.

grep -i accountsservice /var/log/pacman.log

[2016-03-08 12:45] [ALPM] installed accountsservice (0.6.40-2)
[2016-06-16 12:43] [ALPM] upgraded accountsservice (0.6.40-2 -> 0.6.42-1)
[2016-10-12 14:09] [ALPM] upgraded accountsservice (0.6.42-1 -> 0.6.43-1)
[2017-04-22 15:24] [ALPM] upgraded accountsservice (0.6.43-1 -> 0.6.45-1)
[2018-04-05 13:31] [ALPM] upgraded accountsservice (0.6.45-1 -> 0.6.46-1)
[2018-04-25 20:23] [ALPM] upgraded accountsservice (0.6.46-1 -> 0.6.47-1)
[2018-05-12 14:11] [ALPM] upgraded accountsservice (0.6.47-1 -> 0.6.49-1)
[2018-07-11 13:20] [ALPM] upgraded accountsservice (0.6.49-1 -> 0.6.50-1)
[2018-09-27 03:46] [ALPM] upgraded accountsservice (0.6.50-1 -> 0.6.53-1)
[2018-09-29 22:49] [ALPM] upgraded accountsservice (0.6.53-1 -> 0.6.54-1)

If I compare the dates, then 0.6.53-1 may be the faulty package, that leave this directory behind?

BTW: Which package should toss a file for the git user in there, so that the git user is marked as a system user?

Thanks!

edit: corrected english expression

Last edited by sjensen (2018-10-13 20:29:36)

Scimmia · 2018-10-13 19:22:13

https://bugs.archlinux.org/task/60233

That should explain what happened.

loqs · 2018-10-13 19:39:57

About the git user being displayed is probably due to AccountService classifying the git user as none system see https://github.com/freedesktop/accounts … ify.c#L148

sjensen · 2018-10-13 20:26:10

Scimmia wrote:

[,,,] That should explain what happened.

Indeed, thank you very much, Scimmia.

loqs wrote:

About the git user being displayed is probably due to AccountService classifying the git user as none system [...]

As the gnome-control-center shows the git user and you could simply hit "remove user", there is imho a potential risk to completely wreck your system, because the git user has "/" as home. Imho there should be a config for the git user in the AccountsService to hide the user.

eschwartz · 2018-10-14 02:16:41

sjensen wrote:

As the gnome-control-center shows the git user and you could simply hit "remove user", there is imho a potential risk to completely wreck your system, because the git user has "/" as home. Imho there should be a config for the git user in the AccountsService to hide the user.

I guess that would be a problem for any user at all, which it misdetected as a non-system user. Since by default, all system users use / as the home directory.

Fortunately, it prompts you whether you wish to delete data, and furthermore it should be hopefully obvious that the "git" user is not one you were supposed to remove as you didn't add it to begin with.

sjensen · 2018-10-15 18:09:28

So, theoretical, it is an AccountsService "bug" and should be filed? From my humble view, "git" is a system user and should be included in the default exclude list here: https://github.com/freedesktop/accounts … sify.c#L30

I don't think it is the job of "gnome-control-center" to take care of that. Maybe, I don't know.

Last edited by sjensen (2018-10-15 18:10:16)

seth · 2018-10-15 20:46:17

I'd say it's a git bug.
The systemd dynamic user config lists git-shell as the users shell, but git-shell isn't an interactive shell unless the user has ~/git-shell-commands what in this case (because of the / $HOME) means /git-shell-commands must exist rx for the git user (at least)
The entire thing is weird and makes no sense - afaics the git user only exists to run the git daemon, I don't see where it needs a login shell (let alone one, that won't allow for interactive usage by default)

eschwartz · 2018-10-16 05:06:28

And what, precisely, do you suppose the git daemon is?

It's the thing which you can ssh to in order to run git-shell when *not* in interactive mode, in order to have, like, a daemon user which permits the running of git-receive-pack and friends.

This has utterly nothing to do with whether or not ~/git-shell-commands exists.

It's just plain wrong to assume that system users *never* have a login shell configured. And if you look through the arch repos, it's definitely not the only one -- for example, see the postgresql package, or gitlab-shell.

Last edited by eschwartz (2018-10-16 05:09:57)

seth · 2018-10-16 08:42:09

Ah, ok - it acts like ForceCommand on a different layer.
I don't assume anything about system users - accountsservice does.

Do the problems are that
1. sysusers.d has no way to limit the ID range to pick from
2. accountsservice doesn't eg. check whether the account is locked (though it seems to run as root?)
3. git requires a regular shell and doesn't enforce a UID (<500 or <1000)

So on a more informed, revised upstream blaming: fix (2), extend (1) and have (3) make use of that ;-)
Downstream, one could enforce some low UID for git (and apparently other candidates)

eschwartz · 2018-10-16 15:18:13

seth wrote:

Ah, ok - it acts like ForceCommand on a different layer.
I don't assume anything about system users - accountsservice does.

(I didn't say you did, I said it would be wrong to do so, and it is indeed accountsservice that does so. On a separate note, I said that you, seth, could check the arch repositories and discover at least two example packages where accountsservice's assumption is wrong.)

Do the problems are that
1. sysusers.d has no way to limit the ID range to pick from
2. accountsservice doesn't eg. check whether the account is locked (though it seems to run as root?)
3. git requires a regular shell and doesn't enforce a UID (<500 or <1000)
So on a more informed, revised upstream blaming: fix (2), extend (1) and have (3) make use of that ;-)
Downstream, one could enforce some low UID for git (and apparently other candidates)

Why does (1) need to be extended? In fact, it is already true, and you're wrong. sysusers.d by default creates UIDs < 1000, and (3) git does not need to make use of anything, it's the compile-time default for sysusers.d which is only ever meant to create system users.

That being said, sysusers.d has "r" lines which can modify the compile-time default and allocate an explicit pool of UIDs to check for free UIDs that can be assigned to a newly created sysuser.

...

I have no idea why accountsservice apparently, on my system, thinks that UID 995 ("git:x:995:995:git daemon user:/:/usr/bin/git-shell") is one of the standard users and groups to be added/removed.

It is pretty terrible, all right.

But I would care more if I wasn't already quite positive that the only usergroup management I shall do is using useradd/userdel/usermod, and if I need to delete data I shall check it first and then rm it myself.

seth · 2018-10-16 15:37:30

https://github.com/freedesktop/accounts … ify.c#L148 would suggest that the fedora hack (user_heuristics) is enabled in the accountsservice compilation (and that the actually existing password hash heuristic is bogus or the git user somehow got a password) or that the "minimum_uid" is too low.

the only usergroup management I shall do is using useradd/userdel/usermod

+1, but given that at least two people on the forum nuked their system and some linked antergos/manjaro/whatever thread was crowded with similar reports, this sounds like sth. that really needs to be addressed, because you can safely assume that those users neither have a backup strategy…

loqs · 2018-10-16 16:04:02

seth wrote:

https://github.com/freedesktop/accounts … ify.c#L148 would suggest that the fedora hack (user_heuristics) is enabled in the accountsservice compilation (and that the actually existing password hash heuristic is bogus or the git user somehow got a password) or that the "minimum_uid" is too low.

https://github.com/freedesktop/accounts … ons.txt#L5 user_heuristics is by default enabled and minimum_uid is 1000
This does seem to indicate that accountservice's user_classify_is_excluded_by_heuristics function is not detecting locked accounts.
Edit:
AccountService skips the account being locked

#ifdef ENABLE_USER_HEURISTICS
static gboolean
user_classify_is_excluded_by_heuristics (const gchar *username,
                                         const gchar *password_hash)
{
        gboolean ret = FALSE;

        if (password_hash != NULL) {
                /* skip over the account-is-locked '!' prefix if present */
                if (password_hash[0] == '!')
                    password_hash++;

                if (password_hash[0] != '\0') {
                        /* modern hashes start with "$n$" */
                        if (password_hash[0] == '$') {
                                if (strlen (password_hash) < 4)
                                    ret = TRUE;

                        /* DES crypt is base64 encoded [./A-Za-z0-9]*
                         */
                        } else if (!g_ascii_isalnum (password_hash[0]) &&
                                   password_hash[0] != '.' &&
                                   password_hash[0] != '/') {
                                ret = TRUE;
                        }
                }

        }

        return ret;
}
#endif /* ENABLE_USER_HEURISTICS */

#ifdef ENABLE_USER_HEURISTICS
        /* only do heuristics on the range 500-1000 to catch one off migration problems in Fedora */
        if (uid >= 500 && uid < MINIMUM_UID) {
                if (!user_classify_is_excluded_by_heuristics (username, password_hash))
                        return TRUE;
        }
#endif

Last edited by loqs (2018-10-16 16:15:23)

seth · 2018-10-16 16:18:04

Thanks.
user_classify_is_human is true if user_classify_is_excluded_by_heuristics (whatever that means) is false.
The function returns false for null or "!" hashes (ie. it explicitly overreads locks) and only true if the "hash" is not a hash at all.
I won't claim to understand the idea behind that, but that explains the false positive…

I'd kick the user_heuristics, they're only required if you added users starting UID 500 - upstream might want to reconsider the heuristics of locked UIDs w/ empty hashes…

eschwartz · 2018-10-16 16:46:43

Why oh why is user heuristics the default, if it was written specifically and explicitly to allow managing desktop users that lie between 500 and 1000?

For what it's worth, Arch has used UID_MIN=1000 since the we initially imported our PKGBUILDs into svn in 2008, which is as far as I can track...

loqs · 2018-10-16 16:58:08

The port from autotools to meson seems to be the cause of user_heuristics becoming default enabled
https://github.com/freedesktop/accounts … f23a9cce27
Edit:
grammar missing of

Last edited by loqs (2018-10-16 16:58:29)

eschwartz · 2018-10-16 17:31:25

https://gitlab.freedesktop.org/accounts … /issues/57
https://bugs.archlinux.org/task/60432

sjensen · 2018-10-16 22:13:26

Guys, I am impressed and learned a lot. Thank you!

btw: upgraded accountsservice (0.6.54-1 -> 0.6.54+2+g204a4ab-1) and the git user doesn't shows up anymore in gnome-control-center.

Arch Linux

#1 2018-10-13 19:09:39

found a unowned directory "accountsservice"

#2 2018-10-13 19:22:13

Re: found a unowned directory "accountsservice"

#3 2018-10-13 19:39:57

Re: found a unowned directory "accountsservice"

#4 2018-10-13 20:26:10

Re: found a unowned directory "accountsservice"

#5 2018-10-14 02:16:41

Re: found a unowned directory "accountsservice"

#6 2018-10-15 18:09:28

Re: found a unowned directory "accountsservice"

#7 2018-10-15 20:46:17

Re: found a unowned directory "accountsservice"

#8 2018-10-16 05:06:28

Re: found a unowned directory "accountsservice"

#9 2018-10-16 08:42:09

Re: found a unowned directory "accountsservice"

#10 2018-10-16 15:18:13

Re: found a unowned directory "accountsservice"

#11 2018-10-16 15:37:30

Re: found a unowned directory "accountsservice"

#12 2018-10-16 16:04:02

Re: found a unowned directory "accountsservice"

#13 2018-10-16 16:18:04

Re: found a unowned directory "accountsservice"

#14 2018-10-16 16:46:43

Re: found a unowned directory "accountsservice"

#15 2018-10-16 16:58:08

Re: found a unowned directory "accountsservice"

#16 2018-10-16 17:31:25

Re: found a unowned directory "accountsservice"

#17 2018-10-16 22:13:26

Re: found a unowned directory "accountsservice"

Board footer