Bug 506132

Summary:	pam_console_apply[xxxx]: getgrnam failed for audio
Product:	Red Hat Enterprise Linux 5	Reporter:	Jay Turner <jturner>
Component:	udev	Assignee:	Harald Hoyer <harald>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE <qe-baseos-auto>
Severity:	high	Docs Contact:
Priority:	low
Version:	5.4	CC:	ovasik, rbiba, srevivo, syeghiay
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-06-17 09:14:32 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jay Turner 2009-06-15 17:18:37 UTC

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):
2.5.58-7.el5

How reproducible:
Always

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 17:59:48 UTC

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 06:43:05 UTC

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 09:01:40 UTC

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 09:19:26 UTC

why not make gdm the "console user" ?? then all devices will be owned by it

Comment 8 Harald Hoyer 2009-06-17 09:12:30 UTC

# 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