Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
I am moving make_extra_nodes() to /lib/udev/create_extra_nodes. Can /sbin/restorecon /dev/$name be called by this script (which will be used by *both* the init script and postinst) or does it need to be run by the init script (not my favourite choice)? And what about cp --archive --update /lib/udev/devices/* /dev/? Does it need to be moved there as well or is only mknod an issue? -- ciao, Marco signature.asc Description: Digital signature
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
On Wednesday 06 August 2008 22:03, Marco d'Itri [EMAIL PROTECTED] wrote: I am moving make_extra_nodes() to /lib/udev/create_extra_nodes. Can /sbin/restorecon /dev/$name be called by this script (which will be used by *both* the init script and postinst) or does it need to be run by the init script (not my favourite choice)? Yes, restorecon can be called by both. And what about cp --archive --update /lib/udev/devices/* /dev/? Does it need to be moved there as well or is only mknod an issue? Yes, that needs to be moved too. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
On Tuesday 05 August 2008 08:18, Marco d'Itri [EMAIL PROTECTED] wrote: My proposal is to factor out the function which calls mknod, but keep the parts which mount /dev etc as is. That proposal satisfies most of my requirements and will be quite adequate for Lenny. Please make such a change at your earliest convenience and request that the release team include it for Lenny. In the Lenny+1 time-frame we can determine whether any other changes need to be made. Please close this bug when you have made the patch that you propose. I'll open a new bug if I see a need for any further changes. Also please tell me ASAP what name you plan to use for this new file. If you use the name I suggested then no action is required from me. If you use a different name then I need to change the policy to match. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
On Jul 24, Russell Coker [EMAIL PROTECTED] wrote: Exactly, which operations not permitted by initrc_t are being a problem here? E.g. I see many other init script which mount stuff in /dev. But no other scripts that create device nodes, or that mount /dev itself. What about the init scripts which mount arbitrary file systems then? My proposal is to factor out the function which calls mknod, but keep the parts which mount /dev etc as is. -- ciao, Marco signature.asc Description: Digital signature
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
On Wednesday 23 July 2008 21:47, Marco d'Itri [EMAIL PROTECTED] wrote: On Jul 23, Russell Coker [EMAIL PROTECTED] wrote: If we exclude the simplest (and worst) option, then running /etc/init.d/udev as udev_t would require changing run_init (which uses initrc_t exclusively for the scripts it runs) or having run_init call /etc/init.d/udev-runner (or I foolishly expected that init scripts could run in a custom context like other program do... Why this is not possible? The init scripts run in a context that grants privileges appropriate for starting and stopping daemons. They launch processes that may have greater privileges. With software an extremely large number of things are possible, but the number of things that are practical is much smaller. Any other option will require changes to policy and run_init which are not trivial and which will impact my ability to track upstream changes in future. They will also be much more significant than splitting a 300 line shell script into two 150 line shell scripts. If you would like to help me develop SE Linux packages then please let me know, since Manoj moved on to other things I've been lacking time to track everything and would be more than happy to have some assistance. If you would like to merely learn about SE Linux then your best option is to take up my offer of a Xen DomU. Exactly, which operations not permitted by initrc_t are being a problem here? E.g. I see many other init script which mount stuff in /dev. But no other scripts that create device nodes, or that mount /dev itself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
On Jul 23, Russell Coker [EMAIL PROTECTED] wrote: Exactly why can't you fix the SELinux policy? If you define fix to mean make it work with the current udev script then that would involve either running /etc/init.d/udev as udevd_t (which will cause some issues with run_init) What kind of issues? Can't they be worked around? Why moving part of the code to a different program would not be a problem too? The functionality of mounting the tmpfs on /dev and populating it with the bare minimum of devices is separate to the main functionality of udev. Why do you object to splitting the code according to function? For a start, I object on principle to changes requested by the maintainers of other packages who cannot clearly show that changing my package instead of their package is the right thing to do. Then I object to changes I do not understand, because udev is complex and its init script is very complex, so I do not want to have in my package some important code whose implications I do not know about. -- ciao, Marco signature.asc Description: Digital signature
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
On Wednesday 23 July 2008 21:09, Marco d'Itri [EMAIL PROTECTED] wrote: On Jul 23, Russell Coker [EMAIL PROTECTED] wrote: Exactly why can't you fix the SELinux policy? If you define fix to mean make it work with the current udev script then that would involve either running /etc/init.d/udev as udevd_t (which will cause some issues with run_init) What kind of issues? Can't they be worked around? Why moving part of the code to a different program would not be a problem too? Moving the code in question to a different program allows running it under a different security context. The concept is simply that scripts in /etc/init.d will start privileged programs and not do much else. The other programs (in locations such as /sbin) will be more privileged. This means that we can analyse the policy and determine what rights the various programs have. We can make a list of domains which are permitted to perform various privileged operations (such as creating device nodes) and then determine which programs might run in those domains. Being able to exclude all of /etc/init.d from such a list is a good thing (the simplest work-around would be to just permit all scripts in /etc/init.d to do such things). If we exclude the simplest (and worst) option, then running /etc/init.d/udev as udev_t would require changing run_init (which uses initrc_t exclusively for the scripts it runs) or having run_init call /etc/init.d/udev-runner (or some other script that is a wrapper for /etc/init.d/udev). The functionality of mounting the tmpfs on /dev and populating it with the bare minimum of devices is separate to the main functionality of udev. Why do you object to splitting the code according to function? For a start, I object on principle to changes requested by the maintainers of other packages who cannot clearly show that changing my package instead of their package is the right thing to do. Then I object to changes I do not understand, because udev is complex and its init script is very complex, so I do not want to have in my package some important code whose implications I do not know about. The best way of understanding this would be to set up a SE Linux strict configuration machine. Would you like me to give you a Xen DomU for this purpose? I don't think that you will be able to really understand the issues unless you set it up. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
On Jul 23, Russell Coker [EMAIL PROTECTED] wrote: If we exclude the simplest (and worst) option, then running /etc/init.d/udev as udev_t would require changing run_init (which uses initrc_t exclusively for the scripts it runs) or having run_init call /etc/init.d/udev-runner (or I foolishly expected that init scripts could run in a custom context like other program do... Why this is not possible? Exactly, which operations not permitted by initrc_t are being a problem here? E.g. I see many other init script which mount stuff in /dev. -- ciao, Marco signature.asc Description: Digital signature
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
Package: udev
Version: 0.124-3
Severity: normal
With a separate script for setting up udev (mounting tmpfs and creating device
nodes) then we can avoid granting excessive permissions to the regular init.d
scripts under SE Linux. It also makes it a little easier to understand what
the udev script does and therefore easier for anyone else who wants to work
with the code in question.
Here is the new /sbin/start_udev script:
#!/bin/sh -e
# we need to unmount /dev/pts/ and remount it later over the tmpfs
unmount_devpts() {
if mountpoint -q /dev/pts/; then
umount -n -l /dev/pts/
fi
if mountpoint -q /dev/shm/; then
umount -n -l /dev/shm/
fi
}
# mount a tmpfs over /dev, if somebody did not already do it
mount_tmpfs() {
if grep -E -q ^[^[:space:]]+ /dev tmpfs /proc/mounts; then
return
fi
if ! mount -n -o size=$tmpfs_size,mode=0755 -t tmpfs tmpfs /dev; then
log_failure_msg udev requires tmpfs support, not started.
log_end_msg 1
fi
# relabel the new tmpfs accordingly
[ -x /sbin/restorecon ] /sbin/restorecon /dev
return 0
}
# I hate this hack. -- Md
make_extra_nodes() {
if [ $(echo /lib/udev/devices/*) != /lib/udev/devices/* ]; then
cp --archive --update /lib/udev/devices/* /dev/
fi
[ -e /etc/udev/links.conf ] || return 0
grep '^[^#]' /etc/udev/links.conf | \
while read type name arg1; do
[ $type -a $name -a ! -e /dev/$name -a ! -L /dev/$name ] ||continue
case $type in
L) ln -s $arg1 /dev/$name ;;
D) mkdir -p /dev/$name ;;
M) mknod -m 600 /dev/$name $arg1 ;;
*) log_warning_msg links.conf: unparseable line ($type $name $arg1) ;;
esac
if [ -x /sbin/restorecon ]; then
/sbin/restorecon /dev/$name
fi
done
}
# shell version of /usr/bin/tty
my_tty() {
[ -x /bin/readlink ] || return 0
[ -e /proc/self/fd/0 ] || return 0
readlink --silent /proc/self/fd/0 || true
}
warn_if_interactive() {
if [ $RUNLEVEL = S -a $PREVLEVEL = N ]; then
return
fi
TTY=$(my_tty)
if [ -z $TTY -o $TTY = /dev/console -o $TTY = /dev/null ]; then
return
fi
printf \n\n\nIt has been detected that the command\n\n\t$0 $*\n\n
printf has been run from an interactive shell.\n
printf It will probably not do what you expect, so this script will wait\n
printf 60 seconds before continuing. Press ^C to stop it.\n
printf RUNNING THIS COMMAND IS HIGHLY DISCOURAGED!\n\n\n\n
sleep 60
}
##
PATH=/sbin:/bin
# defaults
tmpfs_size=10M
udev_root=/dev
if [ -e /etc/udev/udev.conf ]; then
. /etc/udev/udev.conf
fi
. /lib/lsb/init-functions
##
# this is experimental and may not work well
if [ $UDEV_DISABLED = yes ]; then
udev_root=/etc/udev/.dev
UDEV_ROOT=$udev_root
fi
##
# When modifying this script, do not forget that between the time that the
# new /dev has been mounted and udevadm trigger has been run there will be
# no /dev/null. This also means that you cannot use the shell command.
if [ $udev_root != /dev ]; then
log_warning_msg udev_root != /dev/
if [ -e $udev_root/.udev/ ]; then
if mountpoint -q $udev_root/; then
log_failure_msg udev is already active on $udev_root.
log_end_msg 1
else
log_warning_msg .udev/ already exists on the static $udev_root!
fi
fi
echo /sys/kernel/uevent_helper
mount -n -o size=$tmpfs_size,mode=0755 -t tmpfs tmpfs $udev_root
mkdir -p $udev_root/.udev/db/
log_daemon_msg Starting the hotplug events dispatcher udevd
if udevd --daemon; then
log_end_msg $?
else
log_end_msg $?
fi
log_action_begin_msg Synthesizing initial hotplug events
if udevadm trigger; then
log_action_end_msg $?
else
log_action_end_msg $?
fi
else
if [ -e $udev_root/.udev/ ]; then
if mountpoint -q $udev_root/; then
TMPFS_MOUNTED=1
else
log_warning_msg .udev/ already exists on the static $udev_root!
fi
else
warn_if_interactive
fi
echo /sys/kernel/uevent_helper
if [ -z $TMPFS_MOUNTED ]; then
unmount_devpts
mount_tmpfs
[ -d /proc/1 ] || mount -n /proc
else
# set the SELinux context for devices created in the initramfs
[ -x /sbin/restorecon ] /sbin/restorecon -R /dev
# and clean up the database of the initramfs udev
rm -rf /dev/.udev/
fi
# /dev/null must be created before udevd is started
make_extra_nodes
# if this directory is not present /dev will not be updated by udev
mkdir -p /dev/.udev/db/
fi
Here is the patch for /etc/init.d/udev:
--- udev.orig 2008-07-22 13:18:22.0 +1000
+++ udev2008-07-22 13:34:51.0 +1000
@@ -8,34 +8,6 @@
# Short-Description:
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
On Jul 22, Russell Coker [EMAIL PROTECTED] wrote: With a separate script for setting up udev (mounting tmpfs and creating device nodes) then we can avoid granting excessive permissions to the regular init.d scripts under SE Linux. Exactly, what kind of non-theoretical benefits will this bring? -- ciao, Marco signature.asc Description: Digital signature
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
On Wednesday 23 July 2008 03:32, Marco d'Itri [EMAIL PROTECTED] wrote: On Jul 22, Russell Coker [EMAIL PROTECTED] wrote: With a separate script for setting up udev (mounting tmpfs and creating device nodes) then we can avoid granting excessive permissions to the regular init.d scripts under SE Linux. Exactly, what kind of non-theoretical benefits will this bring? Making SE Linux policy work on Debian as well as it does on Fedora. SE Linux in a strict configuration will work right now in Lenny with this change. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
On Jul 23, Russell Coker [EMAIL PROTECTED] wrote: On Wednesday 23 July 2008 03:32, Marco d'Itri [EMAIL PROTECTED] wrote: On Jul 22, Russell Coker [EMAIL PROTECTED] wrote: With a separate script for setting up udev (mounting tmpfs and creating device nodes) then we can avoid granting excessive permissions to the regular init.d scripts under SE Linux. Exactly, what kind of non-theoretical benefits will this bring? Making SE Linux policy work on Debian as well as it does on Fedora. Please try harder to persuade me. Note that Red Hat does it differently is not an argument I care about much. I do not mind modifying the package to work with SELinux, but I need a detailed explanation of the reason for changes. SE Linux in a strict configuration will work right now in Lenny with this change. Exactly why can't you fix the SELinux policy? -- ciao, Marco signature.asc Description: Digital signature
Bug#491905: Please split the /etc/init.d/udev file as done in Fedora
On Wednesday 23 July 2008 08:35, Marco d'Itri [EMAIL PROTECTED] wrote: SE Linux in a strict configuration will work right now in Lenny with this change. Exactly why can't you fix the SELinux policy? If you define fix to mean make it work with the current udev script then that would involve either running /etc/init.d/udev as udevd_t (which will cause some issues with run_init) or granting all init.d scripts permission to do all the things that udev does (creating device nodes etc). Neither of these are desirable options. The functionality of mounting the tmpfs on /dev and populating it with the bare minimum of devices is separate to the main functionality of udev. Why do you object to splitting the code according to function? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
