Bug 67626 - User not shown at login screen
Summary: User not shown at login screen
Alias: None
Product: accountsservice
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Matthias Clasen
QA Contact:
Depends on:
Reported: 2013-08-01 15:11 UTC by Ray Strode [halfline]
Modified: 2018-08-07 09:30 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Description Ray Strode [halfline] 2013-08-01 15:11:18 UTC
David Woodhouse 2013-07-16 18:03:31 EDT

[root@dwoodhou-mobl3 ~]# grep dwoodhou /etc/passwd
dwoodhou:x:1000:1000:David Woodhouse:/home/dwoodhou:/bin/bash
[root@dwoodhou-mobl3 ~]# grep dwoodhou /etc/shadow

So why am I not shown in the list that gdm offers?

Even if I set a local password (and reboot) I don't show up.

[reply] [−]
Comment 1 David Woodhouse 2013-07-16 18:15:59 EDT

# /usr/libexec/accounts-daemon --debug
(accounts-daemon:1264): DEBUG: entering main loop
(accounts-daemon:1264): DEBUG: skipping user: root
(accounts-daemon:1264): DEBUG: skipping user: bin
(accounts-daemon:1264): DEBUG: skipping user: daemon
(accounts-daemon:1264): DEBUG: skipping user: adm
(accounts-daemon:1264): DEBUG: skipping user: lp
(accounts-daemon:1264): DEBUG: skipping user: sync
(accounts-daemon:1264): DEBUG: skipping user: shutdown
(accounts-daemon:1264): DEBUG: skipping user: halt
(accounts-daemon:1264): DEBUG: skipping user: mail
(accounts-daemon:1264): DEBUG: skipping user: operator
(accounts-daemon:1264): DEBUG: skipping user: games
(accounts-daemon:1264): DEBUG: skipping user: ftp
(accounts-daemon:1264): DEBUG: skipping user: nobody
(accounts-daemon:1264): DEBUG: skipping user: systemd-journal-gateway
(accounts-daemon:1264): DEBUG: skipping user: dbus
(accounts-daemon:1264): DEBUG: skipping user: polkitd
(accounts-daemon:1264): DEBUG: skipping user: abrt
(accounts-daemon:1264): DEBUG: skipping user: usbmuxd
(accounts-daemon:1264): DEBUG: skipping user: colord
(accounts-daemon:1264): DEBUG: skipping user: rpc
(accounts-daemon:1264): DEBUG: skipping user: qemu
(accounts-daemon:1264): DEBUG: skipping user: rtkit
(accounts-daemon:1264): DEBUG: skipping user: ntp
(accounts-daemon:1264): DEBUG: skipping user: tss
(accounts-daemon:1264): DEBUG: skipping user: radvd
(accounts-daemon:1264): DEBUG: skipping user: unbound
(accounts-daemon:1264): DEBUG: skipping user: openvpn
(accounts-daemon:1264): DEBUG: skipping user: saslauth
(accounts-daemon:1264): DEBUG: skipping user: rpcuser
(accounts-daemon:1264): DEBUG: skipping user: nfsnobody
(accounts-daemon:1264): DEBUG: skipping user: avahi
(accounts-daemon:1264): DEBUG: skipping user: avahi-autoipd
(accounts-daemon:1264): DEBUG: skipping user: nm-openconnect
(accounts-daemon:1264): DEBUG: skipping user: mailnull
(accounts-daemon:1264): DEBUG: skipping user: smmsp
(accounts-daemon:1264): DEBUG: skipping user: sshd
(accounts-daemon:1264): DEBUG: skipping user: chrony
(accounts-daemon:1264): DEBUG: skipping user: tcpdump
(accounts-daemon:1264): DEBUG: skipping user: pulse
(accounts-daemon:1264): DEBUG: skipping user: gdm
(accounts-daemon:1264): DEBUG: skipping user: gnome-initial-setup
(accounts-daemon:1264): DEBUG: user dwoodhou has 2 groups
(accounts-daemon:1264): DEBUG: loaded user: dwoodhou
(accounts-daemon:1264): DEBUG: skipping user: root
(accounts-daemon:1264): DEBUG: skipping user: root
(accounts-daemon:1264): DEBUG: skipping user: root
(accounts-daemon:1264): DEBUG: skipping user: root
(accounts-daemon:1264): DEBUG: skipping user: gdm
(accounts-daemon:1264): DEBUG: failed to load gdms custom.conf: Key file does not have key 'AutomaticLoginEnable'
(accounts-daemon:1264): DEBUG: got NameLost, exiting
(accounts-daemon:1264): DEBUG: exiting

<halfline> let me open the bug
<halfline> one second
<dwmw2> but I'm seeing this on new install too.
<halfline> so do any users show up?
<halfline> or just one?
--> giallu (~giallu@host205-187-dynamic.13-79-r.retail.telecomitalia.it) has joined #fedora-desktop
<halfline> that doesn't
<dwmw2> best to use the clean install for this, right?
<dwmw2> in that case, there *are* no other users.
<dwmw2> only 'dwoodhou', the Windows domain user authenticated with pam_winbind.
<halfline> so we get the list of users to show from 3 places
<halfline> 1) /etc/passwd
<dwmw2> I think I was also seeing it on other machines where there's a local 'dwmw2' user too, but let's ignore those for now. 
<halfline> 2) wtmp
<halfline> 3) accountsservice cached users
<halfline> ( they have files in /var/lib/AccountService)
<halfline> your debug spew suggests that accounsservice found your user
<dwmw2> indeed.
<halfline> the list comes directly from there
<dwmw2> gdm doesn't show my user. gdm shows no users.
<halfline> i wonder if you've got the disable-user-list configuration key turned on
<halfline> does it go straight to asking for a Username ?
<-- pbor has quit (Read error: 145 (Connection timed out))
<-- nacho has quit (Read error: 148 (No route to host))
<dwmw2> no, that gives different behaviour
<dwmw2> I did actually turn that on for our setup, just to avoid the bug. 
<halfline> so what exactly do you see?
<dwmw2> then at least the users get a 'Username:' prompt
<halfline> a lone "Not Listed?" item ?
<dwmw2> not just atht 'Not listed?' which they have to click to get the username prompt
<dwmw2> yep
<halfline> so one thing is, the user items are loaded asynchronously
<halfline> and they won't show up in the list until they are fully loaded
<halfline> it could be some bug in libaccountsservice where it's never giving the user object the "loaded=TRUE" property value
<halfline> one second, let me consult the code
<dwmw2> restart gdm and I see
<dwmw2> (accounts-daemon:2073): DEBUG: user gdm 42 excluded
<dwmw2> (accounts-daemon:2073): DEBUG: user dwoodhou 1000 not excluded
<dwmw2> (accounts-daemon:2073): DEBUG: user root 0 excluded
<dwmw2> (accounts-daemon:2073): DEBUG: user gdm 42 excluded
<dwmw2> (accounts-daemon:2073): DEBUG: user dwoodhou 1000 not excluded
<dwmw2> (accounts-daemon:2073): DEBUG: user root 0 excluded
<halfline> sure that's the accounts-daemon talking, i'm wondering what's happening on the client side
<halfline> (gnome-shell)
<halfline> one moment
<halfline> is this f19?
<halfline> oh bug says yes
<dwmw2> yes. Sorry for delay
<halfline> okay i bet i know what the issue is
<halfline>         if (user.locked)
<halfline>            return;
<halfline> i bet it thinks the user account is locked
<dwmw2> shouldn't.
<dwmw2> and I thought I'd set a local password too
<halfline> can you run d-feet for me?
<dwmw2> just to check whether it could tell the difference between "*" and "!!"
<dwmw2> while it's sitting at the login prompt?
<dwmw2> or login and then query accounts-daemon?
<halfline> no, log in
<halfline> or we can use dbus-send i guess
<-- ignatenkobrain has quit (Ping timeout: 600 seconds)
<dwmw2> might be quicker than waiting for yum to install d-feet
<dwmw2> ah, here we are...
<dwmw2> hm, how to make d-feet show me the valid of the Locked property?
<halfline> dbus-send --system --dest=org.freedesktop.Accounts --type=method_call --print-reply /org/freedesktop/Accounts/User1000 org.freedesktop.DBus.Properties.GetAll  string:"org.freedesktop.Accounts.User" | fpaste
<halfline> for d-feet
<halfline> you can double click it
<halfline> though d-feet has a bug
<halfline> where if the value is false
<halfline> it won't show up
<halfline> so if you double-click it and nothing happens then it's false
<dwmw2>       dict entry(
<dwmw2>          string "Locked"
<dwmw2>          variant             boolean false
<dwmw2>       )
<halfline> what about SystemAccount ?
<dwmw2> http://paste.fedoraproject.org/29501/37536793
<dwmw2> SystemAccount true
<halfline> ok
<halfline> so it thinks it's a system account
<halfline> that's why it's not showing up
<halfline> let me see why it's mischaracterizing it
<dwmw2> I removed from the wheel group; that wasn't it
<dwmw2> set a local password. That wasn't it.
<halfline> can you fpaste the file for your user from /var/lib/AccountsService ?
<halfline> if it has SystemAccount=true in the cache entry for your user that would explain the behavior
<halfline> (but not why it got cached as a system user)
<dwmw2> [User]
<dwmw2> Language=en_GB.utf8
<dwmw2> XSession=
<dwmw2> SystemAccount=true
<dwmw2> remove offending file. Restart accounts-daemon, still true
<dwmw2> file not recreated
<halfline> okay so you can either kill accounts service and edit the file, or use d-feet to call the SetSystemAccount method for the user
<halfline> to fix it
<halfline> oh interesting
<halfline> one sec
<halfline> so this function is probably returning TRUE: http://cgit.freedesktop.org/accountsservice/tree/src/daemon.c#n171
<dwmw2> we've now localised it to the accounts-daemon and I can build that and trace it here by myself if that's easier. Thanks for the help.
<dwmw2> 'fedpkg local' running...
<halfline> can you do getent passwd dwoodhou | fpaste ?
<dwmw2> dwoodhou:x:1000:1000:David Woodhouse:/home/dwoodhou:/bin/bash
<dwmw2> that and the equivalent from /etc/shadow are in the bug
<dwmw2> dwoodhou:*:15918:0:99999:7:::
<halfline> ah right
<halfline> thanks
--> mclasen (~mclasen@p449.fei.wifi.vutbr.cz) has joined #fedora-desktop
<-- weld has quit (weld)
<halfline> yea so password_hash == '*' and then we hit the else on line 230 of that file link i posted
<halfline> is not an alphanumeral 
<halfline> and it's not '.' and it's not '/' so it get excluded
<halfline> so that's why it's starting life out as a "system user"
<halfline> then it's getting cached as such
<dwmw2> ah right
<dwmw2> so yes, now I've deleted that cache (which *still* hasn't been recreated), setting a password *does* fix it.
<halfline> okay, of course you shouldn't have to do that
<dwmw2> of  course. But it was confusing that it didn't work, when that was one of my first suspicions :)
<halfline> hmm
<halfline> so this is kind of an interesting case because you have the user in /etc/passwd and it's a remote user
<dwmw2> yeah. Looking up UID/GID/etc against Active Directory is slow and painful
<dwmw2> all we really want is a local user which is *authenticated* against the domain, and then automatically gets a Kerberos TGT kept up to date by winbind, and automatic NTLM authenetication.
<dwmw2> I tried using the winbind nss stuff (and sssd). I really did. And then realised that I really didn't *need* it.
<halfline> so the problem is accountsservice is a big bucket of heuristics
<halfline> tries to detect if a user is "local" by if the user is in /etc/passwd
<dwmw2> there are a bunch of other users with '*' as password field in shadow
<halfline> tries to detect if a user is "system" by if it has a valid password hash
<dwmw2> but those would be excluded by *other* heuristics, surely?
<halfline> unfortunately no
<dwmw2> but those are actually *absent* from my list, rather than being present but marked as system accounts. why?
<dwmw2> the min uid in login.defs mostly, surely?
<halfline> well we don't use login.defs anymore, but even that is insufficient
<halfline> some always leak through
<halfline> because we have %post snippets that call useradd for system users
<halfline> and don't give it a uid
<halfline> so it just picks the next one in the list
<dwmw2> ick :)
<halfline> and some system accounts (like mysql) have a password set
<halfline> because a valid use case is to su to the user to do admin tasks
<halfline> and there's the nobody user of course
<dwmw2> yeah
<halfline> which has a very large uid
<halfline> anyway it's clear we need to muck with the heuristics even more
<halfline> let me mvoe the bug upstream
<halfline> one min
--> drago01 (~linux@chello084113137236.3.13.vie.surfer.at) has joined #fedora-desktop
<dwmw2> as a temporary workaround, I could create /var/lib/AccountsService/users/$USERNAME with SystemAccount=false
<dwmw2> when is that *normally* created? the dæmon doesn't seem to have created it again since I deleted it.
<halfline> well it used to only get created by the CacheUser function
<halfline> which would get called
<halfline> when control-center added a user
<halfline> (remote or local user)
<dwmw2> that hasn't happened here.
<halfline> you didn't add the user via control-center right?
<dwmw2> no, I used python-libuser
<dwmw2> perhaps pyanaconda.users
<dwmw2> (my code used to do the latter, now does the former)
<dwmw2> it's a firstboot module.
<halfline> it also gets created at login time if you pick a non-default session
<dwmw2> Takes company domain credentials, sets up the new installation accordingly
<halfline> but i think it gets created more aggressively now, one sec
<dwmw2> don't *think* I'd done that either; I thought I'd just done a straight install with my repo so I got the firstboot module, then was missing on the first login attempt
<dwmw2> gets created when I log into a GNOME session
<halfline> yea, looks like it only gets created if you use accountsservice api to create the user, or if you log in and change a value it stores to a non-default value
<halfline> if when it's created with control-center it explicitly sets SystemAccount=false in the file
<dwmw2> I can put the file into place, but I need to do so *before* creating the user. Then it'll be read.
<dwmw2> I can cope with that as a workaround for now
<halfline> okay, it's good you have a work around at least
<dwmw2> yeah, that's really useful. Thanks
<halfline> one thing we could do is force SystemAccount=true any time the user gets logged in
<halfline> it's obviously not a system account if they logged in after all
<-- pmkovar has quit (Ping timeout: 600 seconds)
<halfline> but that's not sufficient in and of itself
<dwmw2> indeed.
<halfline> let get this bug filed upstream and i'll think about it more
Comment 1 Ray Strode [halfline] 2013-08-01 15:12:53 UTC
downstream report:

Comment 2 GitLab Migration User 2018-08-07 09:30:28 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/10.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.