Installed from 5RC classic 64bit dvd selecting mate, web server and other server options during install. After reboot, "system user for webserver-base" is offered as a login from lightdm greeter. Reproducible: Steps to Reproduce:
Adding some people. Not sure what is at fault here. I suspect probably lightdm.
CC: (none) => ennael1, mageia, remi, tarakbumbaHardware: i586 => x86_64
Lightdm relies on accountsservice when deciding which users to show in greeter. Could you check the uid of the apache user?
CC: (none) => jani.valimaa
UID/GID 983 but it has a /bin/sh shell
Looks like the heuristics to show users 500-1000 fails in this case as this only happens if the UID is >500. Easy way to test all this is to switch to tty2 from lightdm greeter and alter apache uid via 'usermod -u XXX apache' where XXX is some free uid <500. After switching back to lightdm greeter apache user is disappeared.
Also note, if it's using accountservice then it should be showing in GDM too which uses the same backend. (In reply to Jani Välimaa from comment #4) > Easy way to test all this is to switch to tty2 from lightdm greeter and > alter apache uid via 'usermod -u XXX apache' where XXX is some free uid > <500. After switching back to lightdm greeter apache user is disappeared. I wouldn't recommend changing the UID for the user. That's not a great approach generally as we cannot enforce the UID number on creation (we can only specify the range IDs for system users and they usually fill in from highest first). As Jani said, for IDs >500 and <1000 accountservice has heuristics to determine if it's a "system" account. The real shell is probably the reason that it things it's a real account. Can you change the shell to /bin/false or /sbin/nologin or similar and see if it disappears? If so, the package that creates that user should be updated accordingly as unless the package history states why, there is no reason for a system account like that to have a shell (it doesn't have a shell on fedora/RHEL for example), but we may have some random stuff that means it's needed... I would argue this is done incorrectly if so however.
(also note that fixing this now before release should be fine - it won't affect upgrades as the apache user created on older distros will have id < 500)
(Also note that I wasn't suggesting to change UID to fix the issue, I only provided an easy way to test/prove the issue.)
Confirmed both ways. Altering UID to below 500 does the trick. After changing it back and confirming the user was again displayed in the greeter altered the shell to /bin/false and confirmed it's also gone from the greeter and the same with /sbin/nologin. The httpd service starts ok and "It works!" is displayed with either shell but only tested that far.
CC: (none) => luigiwalser, oe
Web apps often have cron jobs that run as apache. I worry that changing the shell might break something. System users typically have their home directory under /var somewhere. I'd like to see this added to the heuristic for filtering system users.
There're already some excluded users listed in accountsservice source code [1]. I guess we could add apache user there. [1] http://cgit.freedesktop.org/accountsservice/tree/src/user-classify.c#n28
(In reply to Jani Välimaa from comment #10) > There're already some excluded users listed in accountsservice source code > [1]. I guess we could add apache user there. > > [1] http://cgit.freedesktop.org/accountsservice/tree/src/user-classify.c#n28 That's the core set of system users, so service accounts shouldn't be added to that list. Just filter for homedirs in /var and that'll get all of them.
There are already services like postgres, mysql and gdm listed.
(In reply to Jani Välimaa from comment #12) > There are already services like postgres, mysql and gdm listed. Yeah there are loads of package users there, it's not just the core set. As the code doesn't have an infrastructure for doing homedir checks, I've just hacked in apache user for now (I don't have time to write/debug a bigger patch). I'm also not 100% convinced that a user needs a shell configured in their user account to run cron. Isn't it able to specify a shell manually (in the same way as "su -s /bin/sh" can? Anyway, path of least resistance for now is to add a simple patch.
This was fixed in accountsservice-0.6.40-3.mga5 [1]. [1] http://svnweb.mageia.org/packages?view=revision&revision=819488
Status: NEW => RESOLVEDResolution: (none) => FIXED