Description of problem: When I tried to install xguest package in F15, I received the following error: Error in PREIN scriptlet in rpm package xguest-1.0.9-4.fc15.noarch error: %pre(xguest-1.0.9-4.fc15.noarch) scriptlet failed, exit status 1 Version-Release number of selected component (if applicable): [root@mars ~]# yum info xguest Loaded plugins: langpacks, presto, refresh-packagekit Available Packages Name : xguest Arch : noarch Version : 1.0.9 Release : 4.fc15 Size : 31 k Repo : fedora Summary : Creates xguest user as a locked down user URL : http://people.fedoraproject.org/~dwalsh/xguest/ License : GPLv2+ Description : Installing this package sets up the xguest user to be used as a : temporary account to switch to or as a kiosk user account. The : account is disabled unless SELinux is in enforcing mode. The user : is only allowed to log in via gdm. The home and temporary : directories of the user will be polyinstantiated and mounted on : tmpfs. How reproducible: yum install xguest Steps to Reproduce: 1.yum install xguest 2. 3. Actual results: [root@mars ~]# yum -y install xguest Loaded plugins: langpacks, presto, refresh-packagekit Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package xguest.noarch 0:1.0.9-4.fc15 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: xguest noarch 1.0.9-4.fc15 fedora 31 k Transaction Summary ================================================================================ Install 1 Package(s) Total download size: 31 k Installed size: 37 k Downloading Packages: Setting up and reading Presto delta metadata Processing delta metadata Package(s) data still to download: 31 k xguest-1.0.9-4.fc15.noarch.rpm | 31 kB 00:00 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Error in PREIN scriptlet in rpm package xguest-1.0.9-4.fc15.noarch error: %pre(xguest-1.0.9-4.fc15.noarch) scriptlet failed, exit status 1 Failed: xguest.noarch 0:1.0.9-4.fc15 Complete! Expected results: The package is installed. Additional info:
Do you have selinux-policy-targeted installed?
Yes. That package is installed and running. [awang@mars t1]$ rpm -q selinux-policy-targeted selinux-policy-targeted-3.9.16-32.fc15.noarch [awang@mars t1]$ getenforce Enforcing I downloaded the source RPM and it appears it is complaining about the "semanage user -a -S targeted -P xguest -R xguest_r xguest_u 2> /dev/null || :(useradd -c "Guest" -Z xguest_u xguest || semanage login -a -S targeted -s xguest _u xguest || semanage login -m -S targeted -s xguest_u xguest) 2>/dev/null || ex it 1" portion. At least in my system. Thanks.
Created attachment 512714 [details] Can you execute this shell to see what it is complaining about? sh /tmp/xguest.sh
I'm seeing this as well: Cmdline output: $ semanage user -a -S targeted -P xguest -R xguest_r xguest_u $ useradd -c "Guest" -Z xguest_u xguest || semanage login -a -S targeted -s xguest_u xguest || semanage login -m -S targeted -s xguest_u xguest || echo "failed" /usr/sbin/semanage: Linux User xguest does not exist useradd: warning: the user name xguest to xguest_u SELinux user mapping failed. /usr/sbin/semanage: Linux User xguest does not exist /usr/sbin/semanage: Login mapping for xguest is not defined failed $
Here is the output. [root@mars ~]# cd /tmp [root@mars tmp]# chmod a+x xguest.sh [root@mars tmp]# ./xguest.sh + semanage user -a -S targeted -P xguest -R xguest_r xguest_u + echo xguest:exclusive + semanage -S targeted -i -
BTW, I rebuild the package with the downloaded script and it can be installed. I will try to log out my current session and give it a spin later today.
Sorry, I was wrong about what I said before. I guess the reason I didn't run into problem was because I tried on the machine I messed around already. Here is what I got from a "clean" machine. [root@arnoldw tmp]# ./xguest.sh + semanage user -a -S targeted -P xguest -R xguest_r xguest_u + useradd -c Guest -Z xguest_u xguest useradd: warning: the home directory already exists. Not copying any file from skel directory into it. Creating mailbox file: File exists /usr/sbin/semanage: Linux User xguest does not exist useradd: warning: the user name xguest to xguest_u SELinux user mapping failed. + semanage login -a -S targeted -s xguest_u xguest /usr/sbin/semanage: Linux User xguest does not exist + semanage login -m -S targeted -s xguest_u xguest /usr/sbin/semanage: Login mapping for xguest is not defined + exit 1
The work around is I manually create the ID "xguest" first. This allows me to install the package. Now, I'm running into a different problem, on one machine with proprietary nvidia driver installed, I'm having trouble to use the guest account. On a different machine with Intel video card, I don't have problem using the guest account, so far.
Another update. On the machine with nvidia card, I removed the proprietary driver and guest account works fine after that. Of course, this will cause different problem with the new GNOME 3. Oh well...
It looks like the useradd command was failing to add the xguest account, if there was a /home/xguest directory? All of the other errors were caused by this? What AVC were you seeing with the nvidia drivers?
I don't believe that's the case. I've tried this with and without an existing xguest home directory and mailbox and it's failed each time. It seems to me this came about with a recent change to the shadow-utils package or one of the selinux policy packages, as it was working ~ 2 or so weeks ago.
See #701355.
What AVC were you seeing with the nvidia drivers? The following is the output of audit2allow -alr require { type xguest_gkeyringd_t; type xguest_t; type namespace_init_t; type xdm_t; } #============= namespace_init_t ============== files_rw_etc_files(namespace_init_t) #============= xdm_t ============== dev_rw_generic_chr_files(xdm_t) #============= xguest_gkeyringd_t ============== fs_getattr_tmpfs(xguest_gkeyringd_t) #============= xguest_t ============== accountsd_dbus_chat(xguest_t) dev_rw_generic_chr_files(xguest_t) rpm_dbus_chat(xguest_t) I also have the audit log attached.
Created attachment 513328 [details] Audit log
The problem is /dev/nvidiactl is labeled incorrectly. If you run restorecon on it, the label should be fixed and everything should work properly.
Weird, I swear I did "touch /.autorelabel;reboot" when I run into the problem. I will try it again later today. Thanks.
I relabeled the whole system again and still experience the same problem. [awang@mars ~]$ ls -lZ /dev/nvidiactl crw-rw-rw-. root root system_u:object_r:device_t:s0 /dev/nvidiactl Is there anything else you want me to check?
1. You could add /dev/nvidiactl to /etc/selinux/restorecond.conf and run the restorecond service. 2. If you see in the scripts where nvidiactl is created, you could add a restorecon right afterwards. 3. Or you can add a local policy module using # grep gnome-session-c /var/log/audit/audit.log | audit2alllow -M nvidiaisbroken # semodule -i nvidiaisbroken.pp
Daniel Are there any updates/progress to report in regards to failed xguest installation? Thanks
Is there any improvement on this ? I've reproduced the error on intel GPU on i686. I'm running with selinux enforcing. # semanage user -a -S targeted -P xguest -R xguest_r xguest_u # echo $? 0 # useradd -c "Guest" -Z xguest_u xguest useradd: warning: the home directory already exists. Not copying any file from skel directory into it. Creating mailbox file: File exists /usr/sbin/semanage: Linux User xguest does not exist useradd: warning: the user name xguest to xguest_u SELinux user mapping failed. But creating the user without the SE context, then adding the SE context worked: # useradd -c "Guest" xguest # usermod -Z xguest_u xguest yum localinstall xguest (It has just taken more than 5min to install on my Atom N450). Other unrelated remark, is it possible to localize the user comment. I'm using usermod -c 'Invité' xguest
I confirm the problem on a freshly installed Fedora 15, and the work around of comment #20.
I believe a useradd package has just been pushed to fix this problem.
Fixed for me, I think that should be closed as duplicate of #701355
*** This bug has been marked as a duplicate of bug 701355 ***