Thank you for the report. You are clearly living in a more sophisticated & extensive environment than most of us (ox.ac.uk!). Before forwarding this to more learned people, can you elaboarate a little "do not get access to devices such as sound or USB".

CC'ing Dave who should understand this better.

CC: (none) => davidwhodgins, lewyssmith

When you log in pulseaudio doesn't have permission to access the sound devices within /dev/snd and when you plug a USB disk in and try to mount it using the KDE pop-up from the panel it says access denied.

P.S. Changing the permissions on /dev/snd to add read/write for everyone then pulseaudio sees the devices and they work correctly.

P.P.S. This worked correctly in Mageia 6 but broke in 7.

Useful to know.

Real-time reply ! And thank you for the comment 2 clarification.
Another one please: "Non-local users do not get access to devices". Does this mean that the local user does have normal access?

users need to be part of group "audio" in order to access sound devices

This is an issue when working in a heterogeneous computing environment as each operating system would have a different definition of the "audio" group, which is practically guaranteed not to be the same as the local one on a Mageia Linux system and it's impractical to add hundreds of users to each local definition of the group on each machine.

Would this affect USB device access too?

Lewis, locally defined users don't have any problems.

I'm afraid that you've misunderstood.

The account details, and potentially home directory, are held remotely but the login is on the console.

What you describe about the audio devices and the ability for KDE to mount drives worked under Mageia 6 but broke in Mageia 7, hence this bug report and at least the latter is causing operational issues for our researchers.

With respect to the audio group, this is not possible given that each Linux distro and other operating systems such as macOS, *BSD, Solaris etc. will have a different GID for their version of the audio group. Also, adding hundreds, if not thousands of entries to that group in the directory service is untenable and could quite possibly break the directory service. There is no POSIX definition for an audio group GID as far as I'm aware.

The only possible workaround I can think of would be for the desktop at login to start as setgid audio, but that may break the user's primary group affiliation.

It should be noted that other Linux distributions don't seem to have this problem.

Comment 9 should have come after comment 10, but hasn't for some reason.

Users logged in locally do get access to the devices.  It does not matter whether their accounts are defined locally or in NIS/LDAP/AD/etc.  Remote users do not get access by default as that would be a security issue.  If you wanted to do that for some reason, there's nothing preventing you from putting the audio group in NIS.

Systemd-logind is what gives you access to the sound devices when you log in.  This will not be apparent if you run ls -l on the /dev/snd/* devices, but it is if you run getfacl on them.

You can see discussion about this here, among other places:
https://wiki.ubuntu.com/Audio/TheAudioGroup
https://unix.stackexchange.com/questions/202059/is-there-a-way-to-set-permissions-so-a-process-could-use-a-specific-device

USB hard drives are an entirely different issue.  If the device is listed in fstab, users cannot mount it unless the users flag is listed in the options.  Otherwise, KDE will automount things, but if it's a Unix/Linux filesystem, then the ownership and permissions therein will determine if you can access it.

David, re USB hard drives, can you clarify "the ownership and permissions therein will determine if you can access it" - what to look for & where. That is the major issue. It might be easy to make a comparison with another Linux system that works in the same situation.

Stephen's remarks matter:
> the audio devices and the ability for KDE to mount drives worked under
> Mageia 6 but broke in Mageia 7
> the latter is causing operational issues for our researchers
> other Linux distributions don't seem to have this problem
I do not know where best to assign this. tmb & DavidW have commented, hope they are still looking.

I don't believe that anything broke or is broken.  I have seen all of these things work fine on Mageia 7 and things haven't changed in how these functions work.  I even have user accounts in LDAP at home, so I know that things work fine with an external user directory.

It sounds like Stephen's issue is with his systems.  He should check his NSS and PAM configurations and make sure everything sees the NIS users correctly.  Checking logs obviously helps to narrow down issues as well.  This bug should probably be closed as INVALID, and the discuss ml or forum would probably be a better place to seek further help.

As far as USB hard drives, if they have Linux/Unix filesystems, the ownership/permissions on those filesystems will determine who can access them.

I've been running Mandrake/Mandriva/Mageia systems on the research network since the late 90s, along with pretty well every other Linux distribution and UNIX variant and all using our authentication and NFS systems. There was a change in behaviour between Mageia 6 and Mageia 7.

Setting up stock Mageia 6 and 7 systems out of the box, setting nsswitch.conf in the same way, setting network-auth and autofs exactly the same and logging in with the same account and same home directory give different results. On Mageia 6 everything works as it should but on Mageia 7 Pulseaudio can't access /dev/snd/* without manually changing the permission (not work critical) and plugging in a VFAT32 formatted USB stick shows up in the task bar but KDE reports that it doesn't have permission to mount the device when you try to open in File Manager. (Unfortuately I can't get Spectacle to capture the pop-up otherwise I'd attach an image.)

The same system settings work on every other Linux distro we have access to, i.e. Debian/Ubuntu/Mint, Redhat/CentOS, Oracle Linux (SuSE).

If it's not polkit then maybe there's an issue with systemd-logind? The trouble is that there are no diagnostics I can see to determine where it's failing.

> There was a change in behaviour between Mageia 6 and Mageia 7.
> Setting up stock Mageia 6 and 7 systems out of the box
I should have asked sooner how you migrated from M6-M7. I seems from your notes that it was a clean M7[.1] install, rather than an upgrade.
BTAIM Was this recent? One imagines you experienced & reported the problem immediately.
I have cast the net wider for what-to-look-at/for recommendations.

Yes, it was noticed at the beginning of last year but with the COVID stuff I've just not had the head space or time to report it. It's recently come to a head where it's preventing a researcher doing work.

I did post a bug report on pulseaudio last year about the permissions problem there.

The problem is both for machines with a fresh install and upgrade. Whether that's better or worse for discovering what the issue is I don't know. I guess change logs on any sub-systems which might have an influence on this behaviour which changed between 6 and 7 would be a start. (It's still probably a needle in a haystack though.)

A quick search gave me a few results that may be relevant:
https://superuser.com/questions/1563951/systemd-does-not-assign-a-seat-to-my-session-when-using-nis-authentication
https://unix.stackexchange.com/questions/537472/nis-users-sessions-are-incomplete-after-upgrade-to-debian-10

The second one suggests installing nscd fixed it

CC: (none) => pterjan

(https://github.com/systemd/systemd/issues/7074 for the explanation, some sandboxing in systemd now prevents talking to network services, while local nscd will "proxy" it).

Thank-you. I'll investigate.

If this fixes the issue I would suggest that nscd gets installed and enabled automatically if network-auth is enabled as it would obviously be a dependency.

Yes I agree, if this is indeed the problem and the fix we should do it automatically

On the machine I've just tried that does actually seem to have done the trick.

So, nscd definitely needs to be enabled as a dependency of ypbind and other network authentication systems.

P.S. It allows access to the sound and USB drives.

great.

thanks for tracking it down Pascal.

Looking at the service file, installing it should start it at the right time

In authentication.pm we have:

my %kind2packages = (
    local     => [],
    SmartCard => [ 'castella-pam' ],
    LDAP      => [ 'openldap-clients', 'nss-pam-ldapd', 'autofs', 'nss_updatedb' ],
    KRB5       => [ 'nss-pam-ldapd', 'pam_krb5', "${lib}sasl2-plug-gssapi", 'nss_updatedb' ],
    NIS       => [ 'ypbind', 'autofs' ],
    winbind   => [ 'samba-winbind', 'nss-pam-ldapd', 'pam_krb5', "${lib}sasl2-plug-gssapi" ],
);

We could add it there, but I don't know which ones need it.

We could also add a suggests in ypbind package.

BTW, I don't think the rule "users need to be part of group "audio" in order to access sound devices" is hardcoded anywhere, but is probably just a default setting in udev configuration shipped in mandriva. I'm not an expert, but the following part of /usr/lib/udev/rules.d/50-udev-default.rules seems to be relevant:
SUBSYSTEM=="sound", GROUP="audio", \
  OPTIONS+="static_node=snd/seq", OPTIONS+="static_node=snd/timer"

As your environment seems a bit more complex than average one, I'd rather get rid of those constraints instead of trying to comply with an unsuited access control model.

CC: (none) => guillomovitch

[I wrote this before the previous 2 comments]

Pascal (hero of the day):
> suggests installing nscd fixed it
> some sandboxing in systemd now prevents talking to network services,
> while local nscd will "proxy" it).
Stephen (happy customer):
> that does actually seem to have done the trick
> It allows access to the sound and USB drives.
(In reply to Thomas Backlund from comment #23)
> great.
> thanks for tracking it down Pascal.
Thank you indeed Pascal.

Given the agreement on the need to make 'nscd' a dependancy of ... what exactly?
Are we talking loads of packages? That really needs to be done to close the bug.

This bug is for M7; will it apply to M8? If so, and it cannot be done in time, it may need to be in M8ERRATA.

It's a tiny package at 145,216 bytes in Mageia 7. I can't see any reason not
to add it as a requires for the package basesystem. Even though it's not
currently required by anything, I've always included and enabled it in my
installs. I'd also recommend changing it's default to enabled in the preset.

It has caused me hard to debug problems in the past due to caching (you need to know it needs to be reloaded after changes) so I am not sure it is a good idea by default.

Ah. Thanks. That's something I've never encountered. So not a good idea. :-(

May I suggest a different approach then?

How about it is installed by default but not enabled. It only gets enabled when network-auth is enabled as the issue we are trying to fix is to do with network authentication systems.

nscd is an old piece of software, which is only needed in very few situations nowadays, such as centralized account management with old and mostly obsolete non-caching local integration, such as NIS or LDAP + pam_ldap/nss_ldap. Installing it by default, even without activating it, because it may be needed in such kind of situations would be bloating every user base system, just for the benefit of a few limited use cases.

However, having a soft dependency on nscd from ypbind (and samba_winbind, maybe) seem a good idea.

This seems to answer my question in comment 26: for which packages?
ypbind added; it has no regular maintainer.
Added nss-pam-ldapd - guillomovitch.
For samba_winbind, I could not find it at all, so I assumed samba.

It may be an obscure situation, but when it hits - it hits. I have added later releases than 7, assuming the problem would arise there.

OK to assign this to you, Guillaume? Excuse me if the SRPMs are not the right ones.

CC: lewyssmith => (none)
Whiteboard: (none) => MGA7TOO, MGA8TOO
Version: 7 => Cauldron
Source RPM: polkit-0.116-1.mga7.src.rpm => ypbind-1.38-3.mga7.src.rpm, ypbind-2.7.2-2.mga8.src.rpm, samba-4.10.18-1.mga7.src.rpm, samba-4.12.11-1.mga8.src.rpm, nss-pam-ldapd-0.9.11-2.mga8.src.rpm, nss-pam-ldapd-0.9.10-1.mga7.src.rpm
Assignee: bugsquad => guillomovitch

I just resigned as a maintainer for nss-pam-ldapd, as I'm not using it myself for ages. For Samba (for which I'm not even sure nscd is actually useful or not), the question should be adressed to Buchan, which is the maintainer.

For others, it would be a better services for end users to explicitely admit they are unmaintained, rather than looking for someone to fix them every time a new problem is found.

@Stephen; since you have been a long term users/admin on Mandrake / Mageia, how about joining the packaging team?

This could give you the opportunity to tune some packages you're using on a regular basis and sharing your expertises to the community!

Please consider it.
Best,
Chris.

CC: (none) => eatdirt

I have uploaded ypbind-1.38-4.mga7 to 7/core/updates_testing and ypbind-2.7.2-3.mga8 to 8/core/updates_testing which recommend nscd.

ypbind-2.7.2-3.1.mga8.src.rpm was pushed just a few days ago (Bug 28465), so that should include any fixes from ypbind-2.7.2-3.mga8. Changing this to a Mageia 7 bug.

Whiteboard: MGA7TOO => (none)
CC: (none) => andrewsfarm
Version: 8 => 7

If I am understanding the above discussion correctly, what we are doing here is adding nscd as a dependency of ypbind. That is what I will be testing.

Tested in a VirtualBox Mageia 7 64-bit Plasma guest. 

Checked first to see if nscd was installed, and it was not. Installed ypbind and dependencies from the repos, which did not pull in ncsd. Used qarepo to download ypbind-1.38-4.mga7 to a local repo. Updated ypbind, which pulled in nscd as a dependency. No installation issues.

Bug 28465 was pushed on a clean install, with the reporter saying it solved the problem for him. 

Going by Comment 21, installing nscd solved this bug's reporter's problem, so I'm going to give this an OK and validate. Needs an advisory.

Keywords: (none) => validated_update
Whiteboard: (none) => MGA7-64-OK
CC: (none) => sysadmin-bugs

Advisory:
========================

Updated ypbind package fixes a packaging recommend on nscd:

  An issue was discovered that ypbind package should recommend nscd package to
  allow non-local users (whose home is on a remote server) to get access to
  devices connected to the system they are logged.

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

Updated packages in 7/core/updates_testing:
========================
ypbind-1.38-4.mga7

from SRPM:
ypbind-1.38-4.mga7.src.rpm

CC: (none) => ouaurelien

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2021-0091.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED