System users appears in Ligthdm and user switcher (Accountsservice has no filter for shell types)

[Franck]

"Technical" user libvirt Qemu appears in the list of user in Ligthdm, among the real regular users. It probably shouldn't

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: libvirt-bin 2.5.0-3ubuntu2
ProcVersionSignature: Ubuntu 4.9.0-15.16-generic 4.9.5
Uname: Linux 4.9.0-15-generic x86_64
NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity:Unity7
Date: Wed Feb 22 22:09:24 2017
InstallationDate: Installed on 2017-02-01 (21 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Alpha amd64 (20170201)
KernLog:

SourcePackage: libvirt
UpgradeStatus: No upgrade log present (probably fresh install)

[Christian Ehrhardt  (paelzer)]

Hi,
thank you for the report - I can confirm the issue.
This was caused by fixing bug 1637601.
This was brought up on IRC two days ago and I was already polling for opinions on the original but.

There are way more such high-id users in there and I wonder why they would not show up.
Maybe there is some filtering mechanism that I didn't know about yet.

Adding a base-passwd task as they should be the best experts knowing how to deal with that (Authority for allocating such IDs).
Also I'm gonna subscribe all participants of the old bug here.

[Christian Ehrhardt  (paelzer)]

There are also allocations for mysql, ceph and others.
Is libvirt just the one installed on a system with a gui more commonly?
At least mysql should have some footprint ...

Hmm I just checked mysql despite being allocated at 64001 becomes a <1000 number on install.
So that is no good example.

But I found that ceph is using its:
$ id ceph
uid=64045(ceph) gid=64045(ceph) groups=64045(ceph)

Probably for a similar reason as libvirt - to stay consistent across nodes.
I'll check if they show up as well ...

[Christian Ehrhardt  (paelzer)]

I currently only have a KDE/sddm system and there ceph does not show up there.
I'll get access to another system later today and check there for ceph - maybe we can learn the trick from it how to hide.

Maybe I can spawn a new 16.04.2 default ISO to test locally sooner.

[Christian Ehrhardt  (paelzer)]

Note: this is only affecting new installs, as he update keeps the old UID. So if there was a libvirt user it stays as-is.

Ok,
new guest, after installing the software I have several high User IDs:
libvirt-qemu @ 64055
ceph @ 64045

I see, it is "just the same" for ceph.
So it might be a more widespread generic issue that has no solution yet, but libvirt just has more exposure on UI based systems to be noticed faster?

[Christian Ehrhardt  (paelzer)]

The user Objects have an attribute for system accounts:
property Boolean SystemAccount
Whether or not the account is a system account, such as adm. System accounts aren't returned by ListCachedUsers and should generally be ignored.

It also has a shell property, but that (by default) seems to have no impact on listCachedUsers
property String Shell, method SetShell(String path)
The user's login shell.

ListCachedUsers then is what is used by lightdm to fetch the list:
method ListCachedUsers()
returns: users: an array of paths for the user objects
Returns a subset of the users who exist, typically those who have logged in recently, for populating chooser lists such as those used by GDM's greeter.
Currently the accountsservice process scans /etc/passwd for users, filters out those with UID values which are below a threshold point to screen out system users, and sorts the rest by the number of times the users in question appear in /var/log/wtmp. Above a certain length, it's expected that the caller will disregard the list and present only an entry field. The entry field always needs to be available because we know that some results may be missing from this list.

Best API def I found so far is from sssd:
https://fedorahosted.org/sssd/wiki/DesignDocs/AccountsService

Call is from lightdm at load_users in common/user-list.c

This can be reproduced more easily by a direct dbus call:
$ dbus-send --print-reply=literal --system --dest=org.freedesktop.Accounts /org/freedesktop/Accounts org.freedesktop.Accounts.ListCachedUsers

[Christian Ehrhardt  (paelzer)]

So while I understand to unify code paths by relying on accoutnsservice lightdm needs to get back the feature of "hidden-shells=" IMHO.

So in some sense this is a regression in lightdm due to the change to use accountsservice.

The solution clearly extceeds my Dbus-foo, but shouldn't lightdm be able to get back "hidden-shells" by implementing a filter on the "Shell" property of each user that accountsservice provides?

Maybe this was discussed in the lightdm/accountsservice communities - I'm not part of them and search engines didn't find it for me - but given how often the question how to hid users came up I'd think some discussion on the shell filtering might already exist.

Waiting for the expertise of the triagers of lightdm/accountsservice on that bug now.

[Christian Ehrhardt  (paelzer)]

Found more in fidonet and qmail, adding tasks.
But the more that are affected the more I think then general solution in lightdm would be the right thing to do.

[Mauricio Faria de Oliveira (mfo)]

Christian,

Thanks for handling this.

> But the more that are affected the more I think then general solution in lightdm would be the right thing to do.

Yes, that's my interpretation too -- and it was my impression from the beginning, with your report/analysis, as I couldn't find anything we were doing wrong with the useradd of a system account, and specially due to this documentation statement (comment #7):

> [...] filters out those with UID values which are below a threshold point to screen out system users [...]

Which does not cover the possible conditions for a system user (man 8 useradd):

       -r, --system
           Create a system account.

           System users will be created with no aging information in /etc/shadow, and their
           numeric identifiers are chosen in the SYS_UID_MIN-SYS_UID_MAX range, defined in
           /etc/login.defs, instead of UID_MIN-UID_MAX (and their GID counterparts for the
           creation of groups).

           Note that useradd will not create a home directory for such an user, regardless of the
           default setting in /etc/login.defs (CREATE_HOME). You have to specify the -m options
           if you want a home directory for a system account to be created.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Christian Ehrhardt  (paelzer)]

The suggestion was made to add a accountsservice file for it like:
echo -e "[User]\nSystemAccount=true" > /var/lib/AccountsService/users/libvirt-qemu

I agree this might be an option - and I might even be forced to take it at some point, but then I ask myself for how many extra Desktop envs/services would we make extra files if more are found.
Do we really want to make this a custom change in all those packages (and any else in the future who add system users).
- OR -
Wouldn't it make much much more sense to make accountsservice realize on non login shells as all other logins seem to do (e.g. sddm) and as itself did in the past (hidden-shells)?

[Christian Ehrhardt  (paelzer)]

After some IRC discussions I'm increasing prio in accountsservice as more people are convinced this is the place to fix it and it seems to get a rise in "popularity".

[Christian Ehrhardt  (paelzer)]

Hi Ali,
as I outlined before the fix likely has to take place in accountsservice not in libvirt.
You assigned yourself, so I wanted to ask what you have in mind to do?

In case this was an accident you might want to unassign yourself, but "subscribe" [1] you to the bug to stay up to date on this - you find the box to do so to the right of the bug launchpad page.

[1]: https://help.launchpad.net/Bugs/Subscriptions

[Alexander Zhigalin (alexander-v)]

Note to SDDM users:
They won't fix it.
You may want to manually tweak /etc/sddm.conf
For example I changed it to
[Users]
MaximumUid=2000
MinimumUid=1000

So my users are all present and QEMU with UID 64055 has been cut out.

[Gabriel Cotnoir (gcotnoir)]

Note to lightdm users
You can manually tweak /etc/lightdm/users.conf
Add libvirt-qemu to the hidden-users

[pierre (dubiaj)]

Thanks gcotnoir, it's a nice workaround while the bug gets looked into.

[Christian Ehrhardt  (paelzer)]

KDE and Gnome seem to not have the issue in general (To admit - I didn't try myself the Gnome case yet), so in Artful it might be resolved by the switch to Gnome.
I didn't hear from the Desktop Team yet about accountsservice getting a fix.

Also for now there is a workaround in [1]
If this gets no attention for a (more correct and preferred general solution by the desktop Team) we might add that in a libvirt update, but as it is a symptomatic fix only I'd prefer the other solution.
And in turn all the affected packages would have to get such a fix (probably even more and in general as users could add "hidden-shell" type users on their own - and those shouldn't be displayed as well.

[1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1667113/comments/18

[Madan Hegde (madan.hegde)]

I had been facing the same problem along with one more user account named "No value has been set".
For "Libvirt Qemu" tried purging "qemu-kvm" and it's configuration files. But still user account was existed. I had been trying for the solution and found one that you can also try. (I'm using linux mint 18.2 Sonya)

Go to location /etc/ as root and find a file named "passwd" and open it. Now find the line
"libvirt-qemu:x:64055:132:Libvirt Qemu,,,:/var/lib/libvirt:/bin/false" (see the image I attached not to get confused, values may vary in your case) and clear it (don't clear any other line which is not related to "libvirt-qemu"). I found that line almost at the end of the list.

If you're having one more user account named "No value has been set" then clear the line below:
"<admin name>:x:1001:1002:No value has been set:/dev/null:/dev/null" (values may vary in your case)

And now I don't have these user accounts or any other issue after removing those values: "libvirt qemu" and "No value has been set"

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "IMG_20170914_192319.jpg" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Tom Reynolds (tomreyn)]

This is apparently a bug, more precisely a regression (#8) in either Ubuntu's accountservice or lightdm.
This also affects trusty (as I have tested), so adding tag.
There is no patch, yet, removing tag (set in #21), renaming image in #21.
~alisalama has not handled this bug since April, I assume it is not a person, so removing assignment.
Hopefully ~ubuntu-desktop can take a look at this bug sooner or later.

[Christian Ehrhardt  (paelzer)]

Thanks Tom, I agree that loosing the hidden-shells seems to be a regression.
And to make the state more clear that this in the current state is considered a an issue of accountservice or lightdm lets mark the other packages won't fix for now. Otherwise everybody assumes "the other will do it".

This give a better overview and in general it isn't feasible to fix "all-those" and since there can be high-id system-users added manually by users the issue would still persist even when all those other packages would be fixed.

[spike speigel (frail-knight)]

Is this the same issue as bug #857651 ??

[Christian Ehrhardt  (paelzer)]

@Spiegel - yes I think so, thanks for finding the old reference.
Marking as a Dup.

Could someone of the desktop Team give this a look from the 18.04/gnome-shell POV - will this go away?

[Christian Ehrhardt  (paelzer)]

If we stick to depend on accountsservice, then it comes down to the following
$ dbus-send --print-reply=literal --system --dest=org.freedesktop.Accounts /org/freedesktop/Accounts org.freedesktop.Accounts.ListCachedUsers

Which should get some sort of the old hiddenShells feature back to exclude those users.

[Christian Ehrhardt  (paelzer)]

Arrr wanted to send that update to the dup target ...