a workaround is indicated in the ML :

https://mageia.org/pipermail/mageia-dev/2011-June/006084.html

It can be replacing in /etc/pam.d/autologin "system-auth" by "login".
But I don't know if this is the "good way".

Status: NEW => ASSIGNED
Assignee: bugsquad => lists.jjorge

As a workaround, uninstall the autologin package, and use
mcc/drakboot to launch the the graphical environment at system
startup, with autologin selected.

I suspect it's a conflict between the autologin package, and
the autologin built in to kdm/gdm.

CC: (none) => davidwhodgins

(In reply to comment #2)
> I suspect it's a conflict between the autologin package, and
> the autologin built in to kdm/gdm.

No, there is not conflict, and Colin indicated a way to correct it, but he was unsure what is the better way, then no one picked up the problem. I think I will only update autologin package replacing in /etc/pam.d/autologin "system-auth" by "login".

CC: (none) => mageia

Yeah, I don't think anyone really knows here so that's probably the best solution in lieu of anything better :)

Bug fixed with autologin-1.0.0-28.1.mga1 in testing. To test :
- urpmi autologin for core/release
- use mcc to choose autologin
- reboot
- user is first logged in with autologin
- insert a usb stick, it should be refused to access it
- logout, you get kdm or gdm login
- login, you can access the usb stick

With the new version, you can always access usb stick ;-)

Assignee: lists.jjorge => qa-bugs

I'm not seeing any difference with either version of autologin, or
without it.

getfacl is always showing
# file: dev/sdc1
# owner: root
# group: disk
user::rw-
group::rw-
other::---

In all three cases autologin works, and I have no problem accessing
the drive, as my id is in the disk group.

(In reply to comment #6)
> In all three cases autologin works, and I have no problem accessing
> the drive, as my id is in the disk group.

If you create a new user, he will not be in the disk group I think, as this is the case I had. Another think that did not work is 3D : the user could not access the DRI hardware (nouveau-vieux driver)

(In reply to comment #6)
> In all three cases autologin works, and I have no problem accessing
> the drive, as my id is in the disk group.

Sure and if you run everything as root then there are never any permissions problems.... :p

Putting your regular user in groups like this is generally bad practice for a typical desktop system. It might end up breaking things like user switching and multi-seat sustems etc. (you don't want the other users in the internet cafe's multi-headed setup to be able to access the USB drive you insert on your seat do you?).

Console Kit (ck-list-sessions) or these days systemd-logind (systemd-loginctl) will track user sessions and ensure appropriate ACLs are applied. The problem with autologin is that the registration with consolekit was not performed and thus ACLs were not applied.

So any tests on this package should be done without any special group memberships that bypass proper ACL permission rules.

I cannot recreate the problem, although I did find something strange.

Uaing a clean install+updates (not updates testing), running lxde,
when I inserted a usb drive, it was mounted twice, pcmanfm opened
showing the contents of the drive, and a dialog opened providing the
option to open the drive in the file manager, which if ok was clicked
on, would open a second copy of pcmanfm.  The mount command shows
/dev/sdc1 on /media/HODGINS type vfat (rw,nosuid,nodev,uhelper=udisks,uid=500,gid=500,shortname=mixed,dmask=0077,utf8=1,showexec,flush)
/dev/sdc1 on /media/HODGINS-1 type vfat (rw,nosuid,nodev,uhelper=hal,flush,uid=500)

Because of the uid mount option, I have read write access to the drive.
This was using autologin-1.0.0-28.mga1.i586, gdm, with autologin enabled
in mcc.

This update may be needed for cauldron, but it doesn't appear to be
needed for Mageia one.

Not only am I questioning whether the update is needed for Mageia 1,
I'm also questioning whether or not it does anything.

Using autologin-1.0.0-28.1.mga1.src.rpm with gdm, and autologin ...
$ getfacl /dev/sdc*
getfacl: Removing leading '/' from absolute path names
# file: dev/sdc
# owner: root
# group: disk
user::rw-
group::rw-
other::---

# file: dev/sdc1
# owner: root
# group: disk
user::rw-
group::rw-
other::---

so the acl changes do not appear to be happening.

Testing x86_64 with a USB HDD. 

I don't know if they are affected but I would think so.

I'm not able to reproduce the problem.

User is in groups:

$ groups claire
claire : claire lp audio video vboxusers

$ mount
/dev/sda1 on / type ext3 (rw,relatime,commit=0)
none on /proc type proc (rw)
/dev/sda6 on /home type ext3 (rw,relatime,commit=0)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/sdc1 on /media/Backup Drive type ext4 (rw,nosuid,nodev,uhelper=udisks)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
gvfs-fuse-daemon on /home/claire/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=claire)

$ getfacl /dev/sdc*
getfacl: Removing leading '/' from absolute path names
# file: dev/sdc
# owner: root
# group: disk
user::rw-
group::rw-
other::---

# file: dev/sdc1
# owner: root
# group: disk
user::rw-
group::rw-
other::---

I was able to create a file and a directory and a file inside the directory. I'm not sure how I'm able to access it as the permissions seem to deny it but I can do.

Could this be anything to do with HAL?

$ ps ax | grep hal
 1705 ?        Ssl    0:00 hald
 1934 ?        S      0:00 hald-runner
 2043 ?        S      0:00 hald-addon-input: Listening on /dev/input/event0 /dev/input/event4 /dev/input/event2 /dev/input/event3 /dev/input/event5
 2072 ?        S      0:00 hald-addon-storage: polling /dev/sr0 (every 2 sec)
 2096 ?        S      0:00 /usr/lib64/hal/hald-addon-cpufreq
 2098 ?        S      0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
 7636 pts/1    S+     0:00 grep --color hal

$ ll /media
total 8
drwx------ 3 claire claire 4096 Oct 27 09:01 Backup Drive/
drwxr-xr-x 2 root    root    4096 Nov 11  2009 cdrom/

$ cat /etc/mtab
/dev/sda1 / ext3 rw,relatime,commit=0 0 0
none /proc proc rw 0 0
/dev/sda6 /home ext3 rw,relatime,commit=0 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
/dev/sdc1 /media/Backup\040Drive ext4 rw,nosuid,nodev,uhelper=udisks 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
gvfs-fuse-daemon /home/claire/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,user=claire 0 0

Perhaps this does not address ACLs on media devices, but it certainly fixes ACLs on e.g. sound nodes (/dev/snd/*).

Claire, by adding your user to such groups it bypasses any session switch (e.g. multiuser) support etc. These may not be features you use but for QA purposes, unless you have a specific need to put your user in these groups (e.g. your user running apps without logging in) you should maybe consider removing yourself from these groups. Feel free to poke me on IRC if you want to chat about it :)

I don't remember adding the user to any groups Colin. 

I'm not sure which groups you mean? I'll give you a poke :)

(In reply to comment #15)
> Perhaps this does not address ACLs on media devices, but it certainly fixes
> ACLs on e.g. sound nodes (/dev/snd/*).

I went back to a clean install, default groups, gdm with autologin
selected, autologin from Core Release, and ran
getfacl /dev/snd/*>before
Installed autologin from Core Updates Testing and rebooted.
getfacl /dev/snd/*>after
diff before after
showed no changes.

With sox installed,
play /usr/share/sounds/KDE-K3B-Insert-Medium.ogg
does play the sound.

I've taken a closer look at the package.  As it is, it is not functional.

According to /usr/share/doc/autologin/README you have to edit
/etc/sysconfig/autologin, and have run level 5 start an init
script, that starts autologin instead of the dm service.

The package doesn't have the init script.

When autologin is configured in mcc, it configures the package
providing the dm service, gdm, kdm, xdm, etc., to handle the
autologin.  Having this package installed or not, has no impact.

As the package is not functional, either it needs to have the
appropriate init script added, or it should be dropped from
mageia 2, and marked as won't fix for any bug reports in mageia 1.

Opinions?

Sadly your analysis is incorrect as I'm using autologin on a system here without any such fiddling.... this is why I originally posted this fix.

If you follow the script: /etc/X11/prefdm (which is what we use to launch the dm service), then you'll see hooks for autologin in there, 

Don't always believe upstream readme's as integration at the distro level can vary.

While MMC will use gdm, kdm etc's built in login capabilities, this package can and does work and the fixed pam configs are needed. Perhaps what is broken is the updated package in testing.... I'll try and get to the bottom of it.

OK, I cannot see anything obvious in the patch that breaks autologin. I've tested the package here and ensured that it is installed correctly (rpm -V autologin) and the user I specified is indeed in the ACLs on the sound nodes.

Are you sure you do not have a /etc/pam.d/autologin.rpmnew file?

I'm sure.  I just ran three tests, using a clean install, with gdm setup
via mcc to use autologin.

Without the autologin package installed, with the Core version, and with the
Core Updates testing version installed.

In all three cases, getfacl /dev/snd/*, all files except dev/snd/by-path
have ...
# owner: root
# group: audio
user::rw-
user:dave:rw-
group::rw-
mask::rw-
other::---

The package is not having any impact on my system whatsoever.

The reason it is not having any impact, is that mcc does not put the user in
$ cat /etc/sysconfig/autologin
AUTOLOGIN=yes

In /etc/X11/prefdm, it has
# Try autologin first, if wanted...
if [ -f /etc/sysconfig/autologin -a -x /usr/sbin/autologin ]; then
        . /etc/sysconfig/autologin
        if [ -n "$USER" -a "$AUTOLOGIN" = yes ]; then

Since the USER is not set, the /usr/sbin/autologin never gets run.

Unless the user has manually added the USER=id to /etc/sysconfig/autologin,
comment 18 seems to be correct to me.

(In reply to comment #21)
> I'm sure.  I just ran three tests, using a clean install, with gdm setup
> via mcc to use autologin.
> 
> Without the autologin package installed, with the Core version, and with the
> Core Updates testing version installed.
> 
> In all three cases, getfacl /dev/snd/*, all files except dev/snd/by-path
> have ...
> # owner: root
> # group: audio
> user::rw-
> user:dave:rw-
> group::rw-
> mask::rw-
> other::---

But this is correct.... your user dave is in there.

By configuring via mmc, you're telling gdm etc. to audologin and thus bypassing this package itself and the potentially the problem reported.

For reference in my system I don't have gdm, or any login manager installed, just autologin and the autologin is configured manually in the file above.

> The package is not having any impact on my system whatsoever.
> 
> The reason it is not having any impact, is that mcc does not put the user in
> $ cat /etc/sysconfig/autologin
> AUTOLOGIN=yes
> 

Yup, missing USER= in there..


> In /etc/X11/prefdm, it has
> # Try autologin first, if wanted...
> if [ -f /etc/sysconfig/autologin -a -x /usr/sbin/autologin ]; then
>         . /etc/sysconfig/autologin
>         if [ -n "$USER" -a "$AUTOLOGIN" = yes ]; then
> 
> Since the USER is not set, the /usr/sbin/autologin never gets run.
> 
> Unless the user has manually added the USER=id to /etc/sysconfig/autologin,
> comment 18 seems to be correct to me.

No, you don't need any extra initscript as mentioned in comment 18 you just need to put the USER= variable in there and the prefdm script takes care of the rest when starting the regular dm init script.

So the real question is, does installing the old autologin package and putting both AUTOLOGIN=yes and USER=someuser into the sysconfig file break sound and then does the updated package (with it's new pam.d file) fix this problem?

In an ideal world it would also fix disk mounting too - most likely due to proper consolekit registration (compare ck-list-sessions both before and after the upgrade).

HTHs

I can now confirm the problem exists, and this update corrects it.
The problem getting to this point was step 2, in the steps to reproduce,
since using mcc to setup autologin assumes gdm, kdm, etc.

It would be a good idea if the readme in the package were changed to
a README.urpmi with correct instructions to edit /etc/sysconfig/autologin.

Testing on i586 complete for the srpm
autologin-1.0.0-28.1.mga1.src.rpm

Testing complete x86_64

Once it was made clear this was not the autologin used by MCC to auto login found usb disks, sound not working and also not able to restart/shutdown. Only log out was offered as an option.

After update everything is as it should be!

Thankyou Colin for the extra detail :)


I do agree with Dave that it should probably be changed to a README.urpmi

Is that something you'd agree to Colin?

Just noticed, it wasn't coling packaged this.

José could you change the README to a README.urpmi please so it is shown when installing.

Thankyou.

OK, the change is submitted in autologin-1.0.0-28.2.mga1 (and also in Cauldron : autologin-1.0.0-30.mga2)

Might be better to remove the section
"Do I need to do anything else?", since it's handled by prefdm.

The README.urpmi shows up when I install using urpmi, but for
some reason it didn't showup when the update was installed via
mgaapplet.  I guess MageiaUpdate doesn't show the readme for
updates.

Tested OK x86_64

I do agree with Dave though the section mentioned is confusing and not necessary in Mageia. It could lead to breakage.

Do I need to do anything else?
==============================
Yes - you need to have runlevel 5 start autologin. Starting from the
initscripts 5.15 package, Red Hat Linux does this for you.
If you are running a prior version or a different OS, simply replace
the call to kdm, gdm or xdm with a call to autologin, or better yet, to
a script that calls autologin and falls back to [kgx]dm if autologin fails.

well, this is a readme, it is not a script to be blindly followed.

I'll go ahead and validate this update then.

Can someone from the sysadmin team push the srpm
autologin-1.0.0-28.2.mga1.src.rpm
from Core Updates Testing to Core Updates.

Advisory:  This update to the autologin package ensures console kit
will provide correct access control settings for the user logged
in via autologin.

Note: That the /etc/sysconfig/autologin package must be manually
edited to specify the user to login as, and that if enabled, the
setting will override any settings made using mcc.

https://bugs.mageia.org/show_bug.cgi?id=3087

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Update pushed.

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED