RE: Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken

[TaurusHarry <harrytaurus2002@hotmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7614 bytes --]


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@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@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@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

[-- Attachment #2: Type: text/html, Size: 12628 bytes --]