User not shown at login screen
@halfline
Submitted by Ray Strode Assigned to Matthias Clasen @mclasen
Description
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 dwoodhou:*:15902:0:99999:7:::
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] [−] Private 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