You are not logged in.

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

sjensen
Member
From: Germany
Registered: 2018-08-08
Posts: 19

found a unowned directory "accountsservice"

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)

Offline

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

Scimmia
Bug Wrangler
Registered: 2012-09-01
Posts: 7,030

Re: found a unowned directory "accountsservice"

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

That should explain what happened.

Offline

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

loqs
Member
Registered: 2014-03-06
Posts: 6,002

Re: found a unowned directory "accountsservice"

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

Offline

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

sjensen
Member
From: Germany
Registered: 2018-08-08
Posts: 19

Re: found a unowned directory "accountsservice"

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.

Offline

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

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 2,379

Re: found a unowned directory "accountsservice"

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.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

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

sjensen
Member
From: Germany
Registered: 2018-08-08
Posts: 19

Re: found a unowned directory "accountsservice"

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)

Offline

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

seth
Member
Registered: 2012-09-03
Posts: 8,476

Re: found a unowned directory "accountsservice"

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)

Offline

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

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 2,379

Re: found a unowned directory "accountsservice"

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)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

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

seth
Member
Registered: 2012-09-03
Posts: 8,476

Re: found a unowned directory "accountsservice"

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)

Offline

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

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 2,379

Re: found a unowned directory "accountsservice"

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.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

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

seth
Member
Registered: 2012-09-03
Posts: 8,476

Re: found a unowned directory "accountsservice"

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…

Offline

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

loqs
Member
Registered: 2014-03-06
Posts: 6,002

Re: found a unowned directory "accountsservice"

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)

Offline

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

seth
Member
Registered: 2012-09-03
Posts: 8,476

Re: found a unowned directory "accountsservice"

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…

Offline

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

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 2,379

Re: found a unowned directory "accountsservice"

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...


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

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

loqs
Member
Registered: 2014-03-06
Posts: 6,002

Re: found a unowned directory "accountsservice"

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)

Offline

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

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 2,379

Re: found a unowned directory "accountsservice"


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

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

sjensen
Member
From: Germany
Registered: 2018-08-08
Posts: 19

Re: found a unowned directory "accountsservice"

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.

Offline

Board footer

Powered by FluxBB