Bug 506132 - pam_console_apply[xxxx]: getgrnam failed for audio
pam_console_apply[xxxx]: getgrnam failed for audio
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: udev (Show other bugs)
All Linux
low Severity high
: rc
: ---
Assigned To: Harald Hoyer
: Regression
Depends On:
  Show dependency treegraph
Reported: 2009-06-15 13:18 EDT by Jay Turner
Modified: 2015-01-07 19:16 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-17 05:14:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jay Turner 2009-06-15 13:18:37 EDT
Description of problem:
The resolution for bug 244688 involved assigning sound devices to group "audio" if no console user claimed them.  All well and good except for the fact the "audio" group didn't get created.  Net result is messages in /var/log/secure about getgrnam failing for audio:

pam_console_apply[4066]: getgrnam failed for audio

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

How reproducible:

Steps to Reproduce:
1. Check out /var/log/secure after boot/reboot
2. Also, check out /etc/group to see there's no "audio" group defined
Actual results:
Errors in /var/log/secure

Expected results:
"audio" group exists and pam no longer spits out an error message

Additional info:
Without this fix, the fix for bug 244688 is pretty well null and void.  Need to actually create the group in order to make use of it!  This is a behavioral regression resulting from changes committed to RHEL-5.4.
Comment 3 Jay Turner 2009-06-15 13:59:48 EDT
We either need to fix this issue or revert the pam changes outlined in bug 244688.  Otherwise we will drive support volume with the errors in /var/log/secure.
Comment 4 Radek Bíba 2009-06-16 02:43:05 EDT
I'm not sure what "setup" can do about this... group audio is "registered" in the uidgid file, some package (pam? gdm?) just needs to "groupadd" it, right? Or setup could just add audio to the default /etc/group file, but the update of setup won't help since this file is obviously config(noreplace); only new installations would have group audio in /etc/group.
Comment 5 Ondrej Vasik 2009-06-16 05:01:40 EDT
Setup works as expected - in RHEL-5 audio group is registered in uidgid, but not created. In Fedora it is in default /etc/group (#458843), but package which actually uses it - e.g. udev - for the case of updates, which can't be handled by setup, so reassigning to udev. As Radek said - adding group audio to the default /etc/group file will not work for updates - and having post/postun scriptlet in setup is very fragile due to dependencies ...
Harald - what do you think? As udev is widely used and aproved for 5.4, it could probably be created there...
Comment 6 Harald Hoyer 2009-06-16 05:19:26 EDT
why not make gdm the "console user" ?? then all devices will be owned by it
Comment 8 Harald Hoyer 2009-06-17 05:12:30 EDT
# echo gdm > /var/run/console.lock; pam_console_apply
and before the new user is granted login:
# rm /var/run/console.lock

This would fix all of your problems... no need for group audio

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