Bug 173793

if you login via kdm or gdm the permissions
will be provided via resmgr and ACLs, just try:

/sbin/resmgr list
ls -la /dev/snd/

... and if you really want to have new users in audio group, run yast2-users module, go to Expert Options and Defaults for New Users and edit the default.

*** Bug 206806 has been marked as a duplicate of this bug. ***

*** Bug 210936 has been marked as a duplicate of this bug. ***

"/sbin/resmgr list" yields:

status code 200
server message follows:
no devices available

on the topic of resmgr, I also can only access CD/DVDs as root.

Logging in as a samba-authenticated user.

with what mechanism? (text mode? kdm? xdm?)

kdm. Same here.

Last two reporters: Is this 10.2 or 10.1?

For 10.2 resmgr list no longer does list the devices,
instead use:
 hal-resmgr --list=username

10.1 as reported

what is the content of /etc/pam.d/kdm   ?

ll /etc/pam.d/kdm
/bin/ls: /etc/pam.d/kdm: No such file or directory

sorry, its: /etc/pam.d/xdm  

cat /etc/pam.d/xdm
#%PAM-1.0
auth     include        common-auth
account  include        common-account
password include        common-password
session  include        common-session
session  required       pam_devperm.so
session  required       pam_resmgr.so

this looks good (pam_resmgr.so is present)

can you run (as root)
resmgr sessions

and quote the output here?

If you are not on DISPLAY :0   this might be the problem.

You, Novell, do not recommend to log in graphically as root, so I did sux -.

echo $DISPLAY
:0.0

resmgr sessions
status code 200
server message follows:
no sessions

thats actually what i wanted you to do :)

interesting. it seems that you were able to login but bypass
the pam_resmgr module. :/

did you restart resmgr in between being logged in or something?
are there resmgr related messages in /var/log/messages?

Marcus: 10.2, was beta2, now RC1

Logging in via kdm

/etc/pam.d/xdm:
#%PAM-1.0
auth     include        common-auth
account  include        common-account
password include        common-password
session  required       pam_loginuid.so
session  include        common-session
session  required       pam_resmgr.so

resmgr sessions:
:0 YAMATOENGINESjammason

YAMATOENGINES is my Active Directory domain, jammason is my AD username

I've started a new bug, as this seems to be a more general problem with AD (samba) authentication in 10.2.  See bug 223664.

ah, nice. I guess we do not handle the AD specific usernames

what is "id" reporting? 

id:
uid=10000(YAMATOENGINES\jammason) gid=10000(YAMATOENGINES\domain users) groups=10000(YAMATOENGINES\domain users),10001(YAMATOENGINES\hrprograms-editors),10002(YAMATOENGINES\vacation-suspensioncreators),10003(YAMATOENGINES\catalog-editors),10004(YAMATOENGINES\meetingnotes-attendees),10005(YAMATOENGINES\employeeaccess-dataentries),10006(YAMATOENGINES\workinstructions-trainers),10007(YAMATOENGINES\pistonprotrusion-editors),10008(YAMATOENGINES\ows_3373472680_admin),10009(YAMATOENGINES\workinstructions-editors),10010(YAMATOENGINES\catalog-exporters),10011(YAMATOENGINES\vacation-fmlacreators),10012(YAMATOENGINES\processchange-reviewers),10013(YAMATOENGINES\workinstructions-evaluators),10014(YAMATOENGINES\safety team),10015(YAMATOENGINES\mas200),10016(YAMATOENGINES\imglibraryedit),10017(YAMATOENGINES\bomchange-requesters),10018(YAMATOENGINES\notices-editors),10019(YAMATOENGINES\holidays-editors),10020(YAMATOENGINES\is),10021(YAMATOENGINES\tsc),10022(YAMATOENGINES\quality),10023(YAMATOENGINES\vpn access)

I notice that the "resmgr sessions" output does not have the '\' between domain and username.  If I log in at a bash prompt, I have to use the form 'DOMAIN\username'.

yes, this is likely the reason.

we just have not tested it in AD setups up to now.

AD issues are not what the original bug report is about. resmgr on 10.1 cannot properly deal with funny user names or the name mapping games winbind plays. closing as invalid again. The 10.2 problem will be handled in #223664

*** Bug 325551 has been marked as a duplicate of this bug. ***

*** Bug 360607 has been marked as a duplicate of this bug. ***

*** Bug 402744 has been marked as a duplicate of this bug. ***