Bug 26208

Here are the default permissions for /dev/snd:

[root@vanguard ~]# ls -lR /dev/snd
/dev/snd:
total 0
drwxr-xr-x  2 root root       80 Feb 18 10:55 by-path/
crw-rw----+ 1 root audio 116,  5 Feb 18 10:55 controlC0
crw-rw----+ 1 root audio 116, 14 Feb 18 10:55 controlC1
crw-rw----+ 1 root audio 116,  4 Feb 18 10:55 hwC0D0
crw-rw----+ 1 root audio 116, 10 Feb 18 10:55 hwC1D0
crw-rw----+ 1 root audio 116, 11 Feb 18 10:55 hwC1D1
crw-rw----+ 1 root audio 116, 12 Feb 18 10:55 hwC1D2
crw-rw----+ 1 root audio 116, 13 Feb 18 10:55 hwC1D3
crw-rw----+ 1 root audio 116,  3 Feb 18 10:55 pcmC0D0c
crw-rw----+ 1 root audio 116,  2 Feb 18 10:55 pcmC0D0p
crw-rw----+ 1 root audio 116,  6 Feb 18 10:55 pcmC1D3p
crw-rw----+ 1 root audio 116,  7 Feb 18 10:55 pcmC1D7p
crw-rw----+ 1 root audio 116,  8 Feb 18 10:55 pcmC1D8p
crw-rw----+ 1 root audio 116,  9 Feb 18 10:55 pcmC1D9p
crw-rw----+ 1 root audio 116,  1 Feb 18 10:55 seq
crw-rw----+ 1 root audio 116, 33 Feb 18 10:55 timer

/dev/snd/by-path:
total 0
lrwxrwxrwx 1 root root 12 Feb 18 10:55 pci-0000:00:1b.0 -> ../controlC0
lrwxrwxrwx 1 root root 12 Feb 18 10:55 pci-0000:05:00.1 -> ../controlC1

Note: The user is not locally defined in /etc/passwd as it's using network authentication so the user is not in the audio group.

> The /dev/snd files are not accessible to the pulseaudio application by
> default as it doesn't have the correct access rights.
> The user is not locally defined in /etc/passwd as it's using network
> authentication so the user is not in the audio group.
Which user?

> If the permissions on
> the directory are changed then pulseaudio gets access to the sound card and
> operates normally.
Please say permissions changed to what?

Assigning to DavidG as main committer for pulseaudio.

Source RPM: pulseaudio-12.2-5.mga7 => pulseaudio-12.2-5.mga7.src.rpm
CC: (none) => lewyssmith
Assignee: bugsquad => geiger.david68210

The user is one supplied by the NIS service with a home directory automounted and unreadable by root (for security and legal reasons, i.e. GDPR).

Adding other read/write permissions allows pulseaudio to use the device. If the process were running as group 'audio' then it would work.

Thank you for this extra information.
I got stuck on groups, give up.

See also bug 26207, bug 26209.
Assigning globally, CC DavidG as main committer for 'pulseaudio'.

Assignee: geiger.david68210 => pkg-bugs
CC: lewyssmith => geiger.david68210

logind is supposed to set acls for the sound devices. 

To check ACLs you could run:
> getfacl /dev/snd/*

It seems I added myself ages ago to the audio group. Anyone in the audio group can always access these devices. With logind they should only be able to access such devices while logged in.

loginctl would show you if logind knows that someone is logged in.

Not sure how this exactly works, documentation is a bit lacking. I noticed: https://github.com/systemd/systemd/issues/4288 as well as /usr/lib/udev/rules.d/70-uaccess.rules. Seems udev tags anything that should change the ACLs when the active seat (active user basically) with "uaccess". Then probably logind makes those changes.

It seems that in your setup logind needs to be made aware that the user logged in.

This actually looks to be a polkit issue.

If I create a local user (rather than NIS + NFS mounted home directory where the local root does not have read or execute rights) then not only does it have access to the snd devices but also can mount USB drives.

Network users (with unreadable by root home directories) don't get permission to any of the devices. (e.g. plug a USB stick in and you can't open the file manager as it says, "You are not authorized to mount this device.")

Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.

This issue was solved by running nscd if using network authentication as changes in systemd meant that non-local authentication wasn't able to get the correct privileges.

(In reply to Stephen Usher from comment #8)
> This issue was solved by running nscd if using network authentication as
> changes in systemd meant that non-local authentication wasn't able to get
> the correct privileges.

Thanks, closing

Resolution: (none) => WORKSFORME
CC: (none) => marja11
Status: NEW => RESOLVED