Hi Stephen and Justin,
I have got some new findings after I sent out the previous email. The weird error messages about /var/lock/subsys/ turns out to be hard disk inconsistency problem and could be fixed by fsck.ext2, after that, find and touch performed by rc.sysinit or /etc/rc3.d/* would have no problem at all :-)
However, my console still hangs at "INIT: Id "0" respawning too fast: disabled for 5 minutes", although so far I think I have fixed all those obvious problems with SELinux during boot up and I could no longer find fishy AVC denied message except something like:
type=1400 audit(1264435478.992:5): avc: denied { rawip_send } for pid=5 comm="sirq-timer/0" saddr=fe80:0000:0000:0000:0203:baff:fef1:73e3 daddr=ff02:0000:0000:0000:0000:0000:0000:0002 netif=eth5 scontext=system_u:system_r:kernel_t:s15:c0.c255 tcontext=system_u:object_r:netif_t:s0-s15:c0.c255 tclass=netif
type=1400 audit(1264435478.992:6): avc: denied {!
rawip_send } for pid=5 comm="sirq-timer/0" saddr=fe80:0000:0000:0000:0203:baff:fef1:73e3 daddr=ff02:0000:0000:0000:0000:0000:0000:0002 netif=eth5 scontext=system_u:system_r:kernel_t:s15:c0.c255 tcontext=system_u:object_r:node_t:s0-s15:c0.c255 tclass=node
But I don't think they could be the reason /sbin/init would fail to run /sbin/mingetty.
Then I came up with the idea to toggle SELinux state into Permissive mode in the rc.local and finally the console on longer hangs and I could login normally:
root@cp3020:/root>
cat /proc/cmdline
root=/dev/sda1
rw console=ttyS0,115200n8 ip=dhcp selinux=1
BOOT_IMAGE=/vlm-boards/12885/qcao/kernel
root@cp3020:/root>
getenforce
Permissive
root@cp3020:/root>
root@cp3020:/root>
cat /var/log/messages
...
Jan
25 16:59:15 cp3020 /etc/rc3.d/S95atd: atd startup - OK
Jan
25 16:59:15 cp3020 boot: Starting cracklibd
Jan
25 16:59:16 cp3020 boot: Starting local
Jan
25 16:59:16 cp3020 kernel: type=1404 audit(1264438756.016:4):
enforcing=0 ol
d_enforcing=1
auid=4294967295 ses=4294967295
...
root@cp3020:/root>
We can see selinux does boot up WITH enforcing=1 but toggled into enforcing=0 at rc.local, which proves that all my left problem focused on /sbin/mingetty
0:2345:respawn:/sbin/mingetty console (in my /etc/inittab)
Maybe I need to identify the changes from refpolicy-2.20081210 to refpolicy-2.20091117 related with getty_t.
Best regards,
Harry
From: harrytaurus2002@hotmail.com
To: sds@tycho.nsa.gov
Date: Mon, 25 Jan 2010 06:04:16 +0000
CC: refpolicy@oss1.tresys.com; selinux@tycho.nsa.gov
Subject: Re: [refpolicy] Bootup problem with refpolicy-2.20091117 - 3: MAKEDEV ok but /var/lock/subsys/ broken
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 doneLANG=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=075!
5
-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)
+ &am!
p;nbs
p; 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: /v
ar/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
tou
ch: 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
?--------- ? ? &a!
mp;nb
sp; 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
?--------- ? ? &nbs!
p;
; ipmi
?--------- ? ? iscsid
?--------- ? ? local
?--------- ? ? netfs
?---------&!
amp;n
bsp; ? ? ocfs2
?--------- ? ? portmap
?--------- ? ? sendmail
?--------- ? ? &am!
p;nbs
p; 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 handl
e'
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首页! 立刻访问!
聊天+搜索+邮箱 想要轻松出游,手机MSN帮你搞定! 立刻下载!