Bug 28269 - Non-local users do not get access to devices.
Summary: Non-local users do not get access to devices.
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2021-02-01 13:40 CET by Stephen Usher
Modified: 2021-04-24 00:54 CEST (History)
7 users (show)

See Also:
Source RPM: ypbind-1.38-3.mga7.src.rpm
CVE:
Status comment:


Attachments

Description Stephen Usher 2021-02-01 13:40:58 CET
Description of problem:
Users provisioned via networked directory systems, such as NIS, do not get access to devices such as sound or USB meaning that they can't access audio and can't mount USB drives.

Version-Release number of selected component (if applicable):


How reproducible:
Completely.

Steps to Reproduce:
1.Set up a networked user directory system (preferably not on a Mageia server as system accounts and groups may differ.)
2.Provision a user account on that system. The Home directory may or may not be on an NFS server, but it would be preferable.
3.Connect the Mageia system to the directory system, (e.g. LDAP or NIS)
4.Log in as the user.
Comment 1 Lewis Smith 2021-02-01 14:32:57 CET
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

Comment 2 Stephen Usher 2021-02-01 14:36:06 CET
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.
Comment 3 Stephen Usher 2021-02-01 14:37:39 CET
P.S. Changing the permissions on /dev/snd to add read/write for everyone then pulseaudio sees the devices and they work correctly.
Comment 4 Stephen Usher 2021-02-01 14:38:24 CET
P.P.S. This worked correctly in Mageia 6 but broke in 7.
Comment 5 Lewis Smith 2021-02-01 14:48:30 CET
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?
Comment 6 Thomas Backlund 2021-02-01 14:54:30 CET
users need to be part of group "audio" in order to access sound devices
Comment 7 Stephen Usher 2021-02-01 14:59:33 CET
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?
Comment 8 Stephen Usher 2021-02-01 15:00:30 CET
Lewis, locally defined users don't have any problems.
Comment 9 Stephen Usher 2021-02-02 20:17:46 CET
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 10 Stephen Usher 2021-02-02 20:19:23 CET
Comment 9 should have come after comment 10, but hasn't for some reason.
Comment 11 David Walser 2021-02-02 21:00:19 CET
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.
Comment 12 Lewis Smith 2021-02-02 22:03:23 CET
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.
Comment 13 David Walser 2021-02-02 23:53:30 CET
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.
Comment 14 Stephen Usher 2021-02-03 10:41:17 CET
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.
Comment 15 Lewis Smith 2021-02-03 11:56:19 CET
> 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.
Comment 16 Stephen Usher 2021-02-03 12:03:20 CET
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.)
Comment 17 Pascal Terjan 2021-02-03 14:48:43 CET
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

Comment 18 Pascal Terjan 2021-02-03 14:55:07 CET
(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).
Comment 19 Stephen Usher 2021-02-03 15:09:53 CET
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.
Comment 20 Pascal Terjan 2021-02-03 15:12:47 CET
Yes I agree, if this is indeed the problem and the fix we should do it automatically
Comment 21 Stephen Usher 2021-02-03 15:16:29 CET
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.
Comment 22 Stephen Usher 2021-02-03 15:17:05 CET
P.S. It allows access to the sound and USB drives.
Comment 23 Thomas Backlund 2021-02-03 15:18:09 CET
great.

thanks for tracking it down Pascal.
Comment 24 Pascal Terjan 2021-02-03 19:22:41 CET
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.
Comment 25 Guillaume Rousse 2021-02-03 19:35:24 CET
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

Comment 26 Lewis Smith 2021-02-03 19:49:50 CET
[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.
Comment 27 Dave Hodgins 2021-02-04 01:17:17 CET
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.
Comment 28 Pascal Terjan 2021-02-04 01:24:54 CET
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.
Comment 29 Dave Hodgins 2021-02-04 02:36:40 CET
Ah. Thanks. That's something I've never encountered. So not a good idea. :-(
Comment 30 Stephen Usher 2021-02-04 10:09:40 CET
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.
Comment 31 Guillaume Rousse 2021-02-04 18:17:08 CET
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.
Comment 32 Lewis Smith 2021-02-04 20:09:35 CET
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

Comment 33 Guillaume Rousse 2021-02-05 18:40:20 CET
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.
Comment 34 Chris Denice 2021-02-07 17:10:33 CET
@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

Comment 35 Pascal Terjan 2021-02-08 21:44:21 CET
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.
Guillaume Rousse 2021-04-10 16:27:14 CEST

Assignee: guillomovitch => bugsquad

David Walser 2021-04-19 03:55:07 CEST

Whiteboard: MGA7TOO, MGA8TOO => MGA7TOO
Version: Cauldron => 8
Assignee: bugsquad => qa-bugs

Comment 36 Thomas Andrews 2021-04-21 00:08:00 CEST
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

Comment 37 Thomas Andrews 2021-04-21 00:43:19 CEST
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

Comment 38 Aurelien Oudelet 2021-04-23 19:59:51 CEST
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

Aurelien Oudelet 2021-04-23 20:00:47 CEST

Keywords: (none) => advisory

Aurelien Oudelet 2021-04-23 20:00:59 CEST

Source 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 => ypbind-1.38-3.mga7.src.rpm

Comment 39 Mageia Robot 2021-04-24 00:54:33 CEST
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


Note You need to log in before you can comment on or make changes to this bug.