From: harrytaurus2002@hotmail.com (TaurusHarry) Date: Mon, 25 Jan 2010 06:04:16 +0000 Subject: [refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken In-Reply-To: <1264176847.22211.16.camel@moss-pluto.epoch.ncsc.mil> References: , , , <4B53CEB9.3050207@gmail.com> , , , <4B543977.40007@gmail.com> , , , <4B550EB9.50806@gmail.com> , , <1264079995.11002.19.camel@moss-pluto.epoch.ncsc.mil>, , <1264176847.22211.16.camel@moss-pluto.epoch.ncsc.mil> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hi Stephen and Justin, The OS I am using is very similar to RedHat and I have set DISTRO=redhat. I found this report last weekend: https://bugzilla.redhat.com/show_bug.cgi?id=425832, which confirmed that if the tmpfs mounted on /dev has not been properly labeled once mounted, MAKEDEV -x on /dev would generate following error message: Start udev: MAKEDEV: mkdir: File exist Well, this is exactly the same error message I got, and I'd confirmed in my previous email that after log in with enforcing=0, "ls -Z /dev" reveals that /dev has not been labeled, many nodes such as log/stderr etc are still labeled with tmpfs_t. As suggested by another bug report of http://74.125.153.132/search?q=cache:hTh0mCacXPEJ:bugs.debian.org/564196+restoerecon+-R+/dev&cd=2&hl=en&ct=clnk&client=firefox-a, I added "/sbin/restorecon /dev" in /sbin/start_udev after this script mount tmpfs on /dev: # mount the tmpfs on ${udev_root%/}, if not already done LANG=C awk "\$2 == \"${udev_root%/}\" && \$3 == \"tmpfs\" { exit 1 }" /proc/moun ts && { if LANG=C fgrep -q "none ${udev_root%/}/pts " /proc/mounts; then PTSDIR=$(mktemp -d) mount --move $udev_root/pts "$PTSDIR" fi if LANG=C fgrep -q "none ${udev_root%/}/shm " /proc/mounts; then SHMDIR=$(mktemp -d) mount --move $udev_root/shm "$SHMDIR" fi mount -n -o mode=0755 -t tmpfs none "$udev_root" + if [ -n "$selinuxfs" ]; then + /sbin/restorecon /dev > /dev/null 2>&1 + fi mkdir -m 0755 $udev_root/pts mkdir -m 0755 $udev_root/shm if [ -n "$PTSDIR" ]; then mount --move "$PTSDIR" $udev_root/pts rmdir "$PTSDIR" fi if [ -n "$SHMDIR" ]; then mount --move "$SHMDIR" $udev_root/shm rmdir "$SHMDIR" fi ret=$[$ret + $?] } Then the original MAKEDEV error message disappears, but threw up another error message: Starting udev: MAKEDEV: error making /dev/loop0: Permission denied The relevant AVC deneid message implies that initrc_t has no "create" privilege against the fixed_disk_device_t type, so I went on to call storage_tmpfs_filetrans_fixed_disk() interface against initrc_t for the Red Hat distribution: @@ -477,6 +477,7 @@ ifdef(`distro_redhat',` storage_manage_fixed_disk(initrc_t) storage_dev_filetrans_fixed_disk(initrc_t) storage_getattr_removable_dev(initrc_t) + storage_tmpfs_filetrans_fixed_disk(initrc_t) # readahead asks for these auth_dontaudit_read_shadow(initrc_t) BTW, this interface has been called against the distro_debian, so I guess we may need to do it for Red Hat too. What would you think? With the above two changes MAKEDEV could finally run uneventfully. However, I run into some other new error messages: Start udev: [OK] ... Enabling local filesystem quotas: [ OK ] find: /var/lock/subsys/ipmi: Stale NFS file handle find: /var/lock/subsys/portmap: Stale NFS file handle find: /var/lock/subsys/netfs: Stale NFS file handle find: /var/lock/subsys/ocfs2: Stale NFS file handle find: /var/lock/subsys/sshd: Stale NFS file handle ... find: /var/run/evlnotifyd.pid: Stale NFS file handle find: /var/run/sm-client.pid: Stale NFS file handle find: /var/run/sendmail.pid: Stale NFS file handle find: /var/run/crond.pid: Stale NFS file handle find: /var/run/evlactiond.pid: Stale NFS file handle Enabling /etc/fstab swaps: [ OK ] INIT: Entering runlevel: 3 ... Starting portmap: [ OK ] touch: cannot touch `/var/lock/subsys/portmap': Stale NFS file handle touch: cannot touch `/var/lock/subsys/netfs': Stale NFS file handle Mounting other filesystems: [ OK ] touch: cannot touch `/var/lock/subsys/ocfs2': Stale NFS file handle touch: cannot touch `/var/lock/subsys/sshd': Stale NFS file handle ... Starting sm-client: touch: cannot touch `/var/run/sm-client.pid': Stale NFS file handle chown: cannot access `/var/run/sm-client.pid': Stale NFS file handle /sbin/restorecon: lstat(/var/run/sm-client.pid) failed: Stale NFS file handle [ OK ] touch: cannot touch `/var/lock/subsys/sm-client': Stale NFS file handle touch: cannot touch `/var/lock/subsys/boa': Stale NFS file handle ... Starting crond: [FAILED] Starting notification action daemon: [ OK ] touch: cannot touch `/var/lock/subsys/evlaction': Stale NFS file handle Starting atd: [FAILED] touch: cannot touch `/var/lock/subsys/local': Stale NFS file handle INIT: Id "0" respawning too fast: disabled for 5 minutes INIT: no more processes left in this runlevel INIT: Id "0" respawning too fast: disabled for 5 minutes (console hangs ...) I am booting from local hard disk not NFS rootfs. These strange error messages are thrown by the find command in rc.sysinit when it is trying to clean up /var and /etc/rc3.d/* initscripts when they are trying to touch their lock files under /var/lock/subsys/. Moreover, after log in with enforcing=0, "ls -Z /var/lock/subsys/" reveals that despite lock files created(in Permissive mode) under /var/lock/subsys/, their DAC attributes, uid/gid, SELinux security contexts have not been correctly created, and I am even unable to correct them by restorecon: root at cp3020:/root> ls -Z /var/lock/subsys/ ls: cannot access /var/lock/subsys/ipmi: Stale NFS file handle ls: cannot access /var/lock/subsys/portmap: Stale NFS file handle ls: cannot access /var/lock/subsys/netfs: Stale NFS file handle ls: cannot access /var/lock/subsys/ocfs2: Stale NFS file handle ls: cannot access /var/lock/subsys/sshd: Stale NFS file handle ... ls: cannot access /var/lock/subsys/local: Stale NFS file handle -rw-r--r-- root root system_u:object_r:var_lock_t atd ?--------- ? ? boa ?--------- ? ? crond ?--------- ? ? evlaction ?--------- ? ? evlnotify -rw------- root root system_u:object_r:var_lock_t evlog -rw------- root root system_u:object_r:var_lock_t evlogrmt ?--------- ? ? ipmi ?--------- ? ? iscsid ?--------- ? ? local ?--------- ? ? netfs ?--------- ? ? ocfs2 ?--------- ? ? portmap ?--------- ? ? sendmail ?--------- ? ? sm-client ?--------- ? ? sshd -rw------- root root system_u:object_r:var_lock_t syslog-ng ?--------- ? ? xinetd root at cp3020:/root> restorecon -R /var/lock/subsys/ restorecon get context on /var/lock/subsys/ipmi failed: 'Stale NFS file handle' restorecon get context on /var/lock/subsys/portmap failed: 'Stale NFS file handle' restorecon get context on /var/lock/subsys/netfs failed: 'Stale NFS file handle' restorecon get context on /var/lock/subsys/ocfs2 failed: 'Stale NFS file handle' restorecon get context on /var/lock/subsys/sshd failed: 'Stale NFS file handle' ... restorecon get context on /var/lock/subsys/local failed: 'Stale NFS file handle' root at cp3020:/root> Any ideas why some lock files are broken while the rest is correct? Thank you very much! Best regards, Harry _________________________________________________________________ ?????????????????msn????? http://ditu.live.com/?form=TL&swm=1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100125/5fa9bbef/attachment.html