[gentoo-releng] baselayout changes for livecds

[gentoo-releng] baselayout changes for livecds

[Brad House]

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

Ok, these are the necessary changes I've made to baselayout
for livecds.  I've seperated the necessary scripts into a
/sbin/livecd-functions.sh to keep bloat out of functions.sh and
rc.  To summarize the changes, it reads  'cdroot' and 'console' off
the commandline, and it exports $CDBOOT if cdroot is set, and
spawns the proper getty (by rewriting inittab) as specified by
the console command line passed to the kernel (if none is passed,
default ttys are used, and uses auto-login).

2 patches here.
- 1 to baselayout's ebuild to make sure /sbin/livecd-functions.sh
is installed.
- 1 to rc-scripts to add livecd functionality.


TODO (in baselayout):
- autogen random password on boot, for security
- fix misc bootsplash stuff (not livecd related)

PS: these fixes are very non-intrusive, please apply asap.

-Brad

[-- Attachment #2: baselayout-livecd.patch --]
[-- Type: application/octet-stream, Size: 2601 bytes --]

--- /usr/portage/sys-apps/baselayout/baselayout-1.8.6.12-r3.ebuild	2003-12-26 18:21:36.000000000 -0500
+++ /usr/portage/sys-apps/baselayout/baselayout-1.8.6.12-r4.ebuild	2004-01-16 23:03:52.881500760 -0500
@@ -1,6 +1,6 @@
-# Copyright 1999-2003 Gentoo Technologies, Inc.
+# Copyright 1999-2004 Gentoo Technologies, Inc.
 # Distributed under the terms of the GNU General Public License v2
-# $Header: /home/cvsroot/gentoo-x86/sys-apps/baselayout/baselayout-1.8.6.12-r3.ebuild,v 1.1 2003/12/26 23:21:36 azarah Exp $
+# $Header: /home/cvsroot/gentoo-x86/sys-apps/baselayout/baselayout-1.8.6.12-r4.ebuild,v 1.1 2004/01/12 05:27:22 brad_mssw Exp $
 
 # This ebuild needs to be merged "live".  You can't simply make a package
 # of it and merge it later.
@@ -8,7 +8,7 @@
 IUSE="bootstrap build static"
 
 SV="1.4.3.12"
-SVREV="p2"
+SVREV="p5"
 # SysvInit version
 SVIV="2.84"
 
@@ -17,12 +17,15 @@
 DESCRIPTION="Base layout for Gentoo Linux filesystem (incl. initscripts and sysvinit)"
 SRC_URI="ftp://ftp.cistron.nl/pub/people/miquels/software/sysvinit-${SVIV}.tar.gz
 	ftp://sunsite.unc.edu/pub/Linux/system/daemons/init/sysvinit-${SVIV}.tar.gz
-	mirror://gentoo/rc-scripts-${SV}${SVREV}.tar.bz2"
+	http://dev.gentoo.org/~brad_mssw/rc-scripts-${SV}${SVREV}.tar.bz2"
+#	mirror://gentoo/rc-scripts-${SV}${SVREV}.tar.bz2"
 HOMEPAGE="http://www.gentoo.org/"
 
 LICENSE="GPL-2"
 SLOT="0"
-KEYWORDS="~x86 ~amd64 ~ppc ~sparc ~alpha ~mips ~arm ~hppa ~ia64 ~ppc64"
+KEYWORDS="x86"
+RESTRICT="nomirror"
+#KEYWORDS="~x86 ~amd64 ~ppc ~sparc ~alpha ~mips ~arm ~hppa ~ia64 ~ppc64"
 
 DEPEND="virtual/os-headers
 	>=sys-apps/portage-2.0.23"
@@ -330,7 +333,7 @@
 	dosym ../../sbin/modules-update /usr/sbin/update-modules
 	# These moved from /etc/init.d/ to /sbin to help newb systems
 	# from breaking
-	dosbin runscript.sh functions.sh
+	dosbin runscript.sh functions.sh livecd-functions.sh
 	exeinto /lib/rcscripts/sh
 	doexe rc-services.sh rc-daemon.sh rc-help.sh
 	cd ${S}/bin
@@ -366,6 +369,7 @@
 	dosym ../../sbin/depscan.sh /etc/init.d/depscan.sh
 	dosym ../../sbin/runscript.sh /etc/init.d/runscript.sh
 	dosym ../../sbin/functions.sh /etc/init.d/functions.sh
+	dosym ../../sbin/livecd-functions.sh /etc/init.d/livecd-functions.sh
 
 	cd ${S}/src
 	einfo "Installing utilities..."
@@ -490,6 +494,11 @@
 	then
 		rm -f ${ROOT}/etc/init.d/functions.sh
 	fi
+	if [ -e ${ROOT}/etc/init.d/livecd-functions.sh ] && \
+	   [ ! -L ${ROOT}/etc/init.d/livecd-functions.sh ]
+	then
+		rm -f ${ROOT}/etc/init.d/livecd-functions.sh
+	fi
 	if [ -e ${ROOT}/etc/init.d/rc-help.sh ]
 	then
 		rm -f ${ROOT}/etc/init.d/rc-help.sh

[-- Attachment #3: baselayout-rc-scripts-livecd.patch --]
[-- Type: application/octet-stream, Size: 5004 bytes --]

diff -ruN rc-scripts-1.4.3.12p2/sbin/livecd-functions.sh rc-scripts-1.4.3.12p5/sbin/livecd-functions.sh
--- rc-scripts-1.4.3.12p2/sbin/livecd-functions.sh	1969-12-31 19:00:00.000000000 -0500
+++ rc-scripts-1.4.3.12p5/sbin/livecd-functions.sh	2004-01-16 00:33:06.000000000 -0500
@@ -0,0 +1,157 @@
+#!/bin/bash
+# Copyright 1999-2003 Gentoo Technologies, Inc.
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+# Global Variables:
+#    CDBOOT			-- is booting off CD
+#    LIVECD_CONSOLE		-- console that is specified to kernel commandline 
+#				-- (ttyS0, tty1, etc). Only defined if passed to kernel
+#    LIVECD_CONSOLE_BAUD	-- console baudrate specified
+#    LIVECD_CONSOLE_PARITY	-- console parity specified
+#    LIVECD_CONSOLE_DATABITS	-- console databits specified
+
+
+livecd_parse_opt() {
+        case "$1" in
+                *\=*)
+                        echo "$1" | cut -f2 -d=
+                ;;
+        esac
+}
+
+livecd_console_settings() {
+	# scan for a valid baud rate
+	case "$1" in
+		300*)
+			LIVECD_CONSOLE_BAUD=300
+		;;
+		600*)
+			LIVECD_CONSOLE_BAUD=600
+		;;
+		1200*)
+			LIVECD_CONSOLE_BAUD=1200
+		;;
+		2400*)
+			LIVECD_CONSOLE_BAUD=2400
+		;;
+		4800)
+			LIVECD_CONSOLE_BAUD=4800
+		;;
+		9600*)
+			LIVECD_CONSOLE_BAUD=9600
+		;;
+		14400*)
+			LIVECD_CONSOLE_BAUD=14400
+		;;
+		28800*)
+			LIVECD_CONSOLE_BAUD=28800
+		;;
+		38400*)
+			LIVECD_CONSOLE_BAUD=38400
+		;;
+		57600*)
+			LIVECD_CONSOLE_BAUD=57600
+		;;
+		115200*)
+			LIVECD_CONSOLE_BAUD=115200
+		;;
+	esac
+	if [ "${LIVECD_CONSOLE_BAUD}" = "" ]
+	then
+		# If it's a virtual console, set baud to 38400, if it's a serial
+		# console, set it to 9600 (by default anyhow)
+		case ${LIVECD_CONSOLE} in 
+			tty[0-9])
+				LIVECD_CONSOLE_BAUD=38400
+			;;
+			*)
+				LIVECD_CONSOLE_BAUD=9600
+			;;
+		esac
+	fi
+	export LIVECD_CONSOLE_BAUD
+
+	# scan for a valid parity
+	# If the second to last byte is a [n,e,o] set parity
+	local parity
+	parity=`echo $1 | rev | cut -b 2-2`
+	case "$parity" in
+		[neo])
+			LIVECD_CONSOLE_PARITY=$parity
+		;;
+	esac
+	export LIVECD_CONSOLE_PARITY	
+
+	# scan for databits
+	# Only set databits if second to last character is parity
+	if [ "${LIVECD_CONSOLE_PARITY}" != "" ]
+	then
+		LIVECD_CONSOLE_DATABITS=`echo $1 | rev | cut -b 1`
+	fi
+	export LIVECD_CONSOLE_DATABITS
+	return 0
+}
+
+
+livecd_read_commandline() {
+        local CMDLINE
+
+# Line to be used for testing only. The formatting of the console=
+# prompt can be found in /usr/src/linux/Documentation/serial-console.txt
+# possible cmdline could look like this: CMDLINE="cdroot console=ttyS0,9600n8"
+
+	CMDLINE=`cat /proc/cmdline`
+
+	for x in ${CMDLINE}
+	do
+		case "${x}" in
+			cdroot)
+				CDBOOT="yes"
+				export CDBOOT
+			;;
+			console\=*)
+				local live_console
+				live_console=`livecd_parse_opt "${x}"`
+
+				# Parse the console line. No options specified if
+				# no comma
+				LIVECD_CONSOLE=`echo ${live_console} | cut -f1 -d,`
+				if [ "${LIVECD_CONSOLE}" = "" ]
+				then
+					# no options specified
+					LIVECD_CONSOLE=${live_console}
+				else
+					# there are options, we need to parse them
+					local livecd_console_opts
+					livecd_console_opts=`echo ${live_console} | cut -f2 -d,`
+					livecd_console_settings  ${livecd_console_opts}
+				fi
+				export LIVECD_CONSOLE
+			;;
+		esac
+	done
+	return 0
+}
+
+
+livecd_fix_inittab() {
+	if [ "${CDBOOT}" = "" ]
+	then
+		return 1
+	fi
+
+	# Comment out current getty settings
+	sed -i -e '/^c[0-9]/ s/^/#/' /etc/inittab	
+
+	if [ "${LIVECD_CONSOLE}" = "tty0" -o "${LIVECD_CONSOLE}" = "" ]
+	then
+		for x in 1 2 3 4 5 6
+		do
+			echo "c${x}:12345:respawn:/sbin/mingetty --noclear --autologin root tty${x}" >> /etc/inittab
+		done	
+	else
+		echo "c1:12345:respawn:/sbin/agetty ${LIVECD_CONSOLE_BAUD} ${LIVECD_CONSOLE} linux" >> /etc/inittab
+	fi
+	return 0
+}
diff -ruN rc-scripts-1.4.3.12p2/sbin/rc rc-scripts-1.4.3.12p5/sbin/rc
--- rc-scripts-1.4.3.12p2/sbin/rc	2003-12-25 19:25:24.000000000 -0500
+++ rc-scripts-1.4.3.12p5/sbin/rc	2004-01-16 23:10:40.880824792 -0500
@@ -6,6 +6,7 @@
 
 trap ":" INT QUIT TSTP
 source /sbin/functions.sh
+source /sbin/livecd-functions.sh
 umask 022
 
 try() {
@@ -163,6 +164,11 @@
 	try try mount -n -t proc none /proc
 	eend $?
 
+	# Read off the kernel commandline to see if there's any special settings
+	# especially check to see if we need to set the  CDBOOT environment variable
+	# Note: /proc MUST be mounted
+	livecd_read_commandline
+
 	if [ -d /sys -a "$(get_KV)" -ge "$(KV_to_int '2.6.0')" ]
 	then
 		ebegin "Mounting sysfs at /sys"
@@ -410,6 +416,17 @@
 		mount --bind "${tsvcdir}" "${svcdir}"
 	fi
 
+	# If booting off CD, we want to rewrite inittab before setting the runlevel
+	if [ "${CDBOOT}" != "" ]
+	then
+		ebegin "Rewriting inittab"
+		livecd_fix_inittab
+		eend $?
+		ebegin "Running telinit q to reload inittab"
+		/sbin/telinit q
+		eend $?
+	fi
+
 	# Clear $svcdir from stale entries
 	rm -rf "${svcdir}"/*
 

[-- Attachment #4: Type: text/plain, Size: 40 bytes --]

--
gentoo-releng@gentoo.org mailing list

[gentoo-releng] Re: baselayout changes for livecds

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1145 bytes --]

On Saturday 17 January 2004 05:23, Brad House wrote:
> Ok, these are the necessary changes I've made to baselayout
> for livecds.  I've seperated the necessary scripts into a
> /sbin/livecd-functions.sh to keep bloat out of functions.sh and
> rc.  To summarize the changes, it reads  'cdroot' and 'console' off
> the commandline, and it exports $CDBOOT if cdroot is set, and
> spawns the proper getty (by rewriting inittab) as specified by
> the console command line passed to the kernel (if none is passed,
> default ttys are used, and uses auto-login).
>
> 2 patches here.
> - 1 to baselayout's ebuild to make sure /sbin/livecd-functions.sh
> is installed.
> - 1 to rc-scripts to add livecd functionality.
>
>
> TODO (in baselayout):
> - autogen random password on boot, for security
> - fix misc bootsplash stuff (not livecd related)

Will there be a way to keep these of of hd installs. I don't think that this 
kind of functionality is good on hd installs. It makes it too easy to create 
an insecure system

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: baselayout changes for livecds

[Brad House]

don't have a clue what you mean by this statement
It is only applicable if you pass  cdroot  to your kernel.
If you're using a genkernel compiled kernel, that will
cause your system to not boot unless you're booting off a
cd.  And for advanced users who actually build their own
kernel, I think they'd be brighter than to try to do autologin
stuff by passing cdroot to the kernel.

Sorry, linux is not idiot-proof. This is a NON-ISSUE.

-Brad


> Will there be a way to keep these of of hd installs. I don't think that
> this
> kind of functionality is good on hd installs. It makes it too easy to
> create
> an insecure system


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Pieter Van den Abeele]

I think what paul means is that when a bootloader isn't password 
protected, a malign user could pass 'cdroot' to the kernel and exploit 
some of the things this triggers in the rc scripts (autologin?) if 
those scripts directly parse the arguments passed to the kernel.

The style of exploit is quite similar to passing:

init=/home/hacker/exploit.sh or init=/bin/sh

to the kernel on a system one has direct access to and whose bootloader 
isn't pass-protected. This issue is relevant for computers from 
computer rooms used for teaching/exams...

But if I'm not mistaken the rc-scripts themselves do not 'parse kernel 
output', it's the linuxrc which parses the kernel arguments , and 
exports cdboot to the env, right? So there should be no security issues 
for systems which don't have an initrd and thus no linuxrc.

Pieter

On 17 Jan 2004, at 17:28, Brad House wrote:

> don't have a clue what you mean by this statement
> It is only applicable if you pass  cdroot  to your kernel.
> If you're using a genkernel compiled kernel, that will
> cause your system to not boot unless you're booting off a
> cd.  And for advanced users who actually build their own
> kernel, I think they'd be brighter than to try to do autologin
> stuff by passing cdroot to the kernel.
>
> Sorry, linux is not idiot-proof. This is a NON-ISSUE.
>
> -Brad
>
>
>> Will there be a way to keep these of of hd installs. I don't think 
>> that
>> this
>> kind of functionality is good on hd installs. It makes it too easy to
>> create
>> an insecure system
>
>
> --
> gentoo-releng@gentoo.org mailing list
>


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Brad House]

no, the rcscripts must now parse the kernel commandline opts
to get a few options. There's really not many other ways to
do it.  Besides you just proved by your statement that someone
could instead pass   init=/bin/sh  and override any sort of
init process, so trying to make the 'cdroot' option secure
is obsurd, as there's 10 million other ways to get in if you
have direct access to the computer.

-Brad

> I think what paul means is that when a bootloader isn't password
> protected, a malign user could pass 'cdroot' to the kernel and exploit
> some of the things this triggers in the rc scripts (autologin?) if
> those scripts directly parse the arguments passed to the kernel.
>
> The style of exploit is quite similar to passing:
>
> init=/home/hacker/exploit.sh or init=/bin/sh
>
> to the kernel on a system one has direct access to and whose bootloader
> isn't pass-protected. This issue is relevant for computers from
> computer rooms used for teaching/exams...
>
> But if I'm not mistaken the rc-scripts themselves do not 'parse kernel
> output', it's the linuxrc which parses the kernel arguments , and
> exports cdboot to the env, right? So there should be no security issues
> for systems which don't have an initrd and thus no linuxrc.
>
> Pieter
>
> On 17 Jan 2004, at 17:28, Brad House wrote:
>
>> don't have a clue what you mean by this statement
>> It is only applicable if you pass  cdroot  to your kernel.
>> If you're using a genkernel compiled kernel, that will
>> cause your system to not boot unless you're booting off a
>> cd.  And for advanced users who actually build their own
>> kernel, I think they'd be brighter than to try to do autologin
>> stuff by passing cdroot to the kernel.
>>
>> Sorry, linux is not idiot-proof. This is a NON-ISSUE.
>>
>> -Brad
>>
>>
>>> Will there be a way to keep these of of hd installs. I don't think
>>> that
>>> this
>>> kind of functionality is good on hd installs. It makes it too easy to
>>> create
>>> an insecure system
>>
>>
>> --
>> gentoo-releng@gentoo.org mailing list
>>
>
>
> --
> gentoo-releng@gentoo.org mailing list
>
>
>


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Pieter Van den Abeele]

I don't care so much about this security issue because assuming that 
you are using a function in a scope shared by the rc scripts and 
haven't hard coded the way to read such arguments in every rc-script, 
it would be trivial to add  some security measures later on.

However from a alternative platform/architecture point of view I have 
to note that at least a kernel dependent strategy might be needed here. 
I wonder whether kernels such as for instance the hurd pass arguments 
the same way as a linux kernel and whether newer linux kernel releases 
might not change this process, thus requiring different rc scripts for 
each kernel while only a different runtime strategy is needed. 
Currently not an urgent issue, but we'll have to take this into 
account.

Pieter

On 17 Jan 2004, at 18:06, Brad House wrote:

> no, the rcscripts must now parse the kernel commandline opts
> to get a few options. There's really not many other ways to
> do it.  Besides you just proved by your statement that someone
> could instead pass   init=/bin/sh  and override any sort of
> init process, so trying to make the 'cdroot' option secure
> is obsurd, as there's 10 million other ways to get in if you
> have direct access to the computer.
>
> -Brad


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 880 bytes --]

On Saturday 17 January 2004 18:06, Brad House wrote:
> no, the rcscripts must now parse the kernel commandline opts
> to get a few options. There's really not many other ways to
> do it.  Besides you just proved by your statement that someone
> could instead pass   init=/bin/sh  and override any sort of
> init process, so trying to make the 'cdroot' option secure
> is obsurd, as there's 10 million other ways to get in if you
> have direct access to the computer.

The big difference is that init=/bin/sh does not give you a normal working 
system, cdboot however could be abused to get a normal functioning 
passwordless console. That would allow incapable systemadmins to decide to do 
this, or even tell others to do it (the latter I want to prevent).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: baselayout changes for livecds

[Martin Schlemmer]

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

On Sat, 2004-01-17 at 20:29, Paul de Vrieze wrote:
> On Saturday 17 January 2004 18:06, Brad House wrote:
> > no, the rcscripts must now parse the kernel commandline opts
> > to get a few options. There's really not many other ways to
> > do it.  Besides you just proved by your statement that someone
> > could instead pass   init=/bin/sh  and override any sort of
> > init process, so trying to make the 'cdroot' option secure
> > is obsurd, as there's 10 million other ways to get in if you
> > have direct access to the computer.
> 
> The big difference is that init=/bin/sh does not give you a normal working 
> system, cdboot however could be abused to get a normal functioning 
> passwordless console. That would allow incapable systemadmins to decide to do 
> this, or even tell others to do it (the latter I want to prevent).
> 

I _did_ say it already, but you apparently did not want to listen - the
kernel opts is not needed, as there is no need to be dynamic.  Its
either a livecd or not.  And as Paul did mention, it might be open for
exploit, although 'init=/bin/bash' will work as well.

The baselayout ebuild will be modified to do changes if USE=livecd, as
it is sane, and I imagine some other things will need special livecd
tweaking as well.  Meaning, if USE=livecd, pkg_postinst() will
'echo CDBOOT=1 >> ${ROOT}/etc/rc.conf', and do whatever else.


Thanks,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: baselayout changes for livecds

[Brad House]

well, I hate to tell you, but 99% of the patch deals with stuff
not related to the kernel reading cdroot off the command
line.  Also, CDBOOT was being put to the end of the rc.conf already,
but it did not appear to work, and we are using the cdroot command
line already specific to genkernel's initrd, so it was a non-wasteful
way to implement it.

I don't have time to argue on this stuff.  The patch is sane,
it needs to be committed, yes there are other ways to do it,
but unless you have another option real soon,
that is tested and works, we're going to need something
in baselayout.

Azarah, did you not get my patches? Have you looked at them?

-Brad

> On Sat, 2004-01-17 at 20:29, Paul de Vrieze wrote:
>> On Saturday 17 January 2004 18:06, Brad House wrote:
>> > no, the rcscripts must now parse the kernel commandline opts
>> > to get a few options. There's really not many other ways to
>> > do it.  Besides you just proved by your statement that someone
>> > could instead pass   init=/bin/sh  and override any sort of
>> > init process, so trying to make the 'cdroot' option secure
>> > is obsurd, as there's 10 million other ways to get in if you
>> > have direct access to the computer.
>>
>> The big difference is that init=/bin/sh does not give you a normal
>> working
>> system, cdboot however could be abused to get a normal functioning
>> passwordless console. That would allow incapable systemadmins to decide
>> to do
>> this, or even tell others to do it (the latter I want to prevent).
>>
>
> I _did_ say it already, but you apparently did not want to listen - the
> kernel opts is not needed, as there is no need to be dynamic.  Its
> either a livecd or not.  And as Paul did mention, it might be open for
> exploit, although 'init=/bin/bash' will work as well.
>
> The baselayout ebuild will be modified to do changes if USE=livecd, as
> it is sane, and I imagine some other things will need special livecd
> tweaking as well.  Meaning, if USE=livecd, pkg_postinst() will
> 'echo CDBOOT=1 >> ${ROOT}/etc/rc.conf', and do whatever else.
>
>
> Thanks,
>
> --
>
> Martin Schlemmer
> Gentoo Linux Developer, Desktop/System Team Developer
> Cape Town, South Africa
>
>
>


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Martin Schlemmer]

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

On Sat, 2004-01-17 at 20:29, Paul de Vrieze wrote:
> On Saturday 17 January 2004 18:06, Brad House wrote:
> > no, the rcscripts must now parse the kernel commandline opts
> > to get a few options. There's really not many other ways to
> > do it.  Besides you just proved by your statement that someone
> > could instead pass   init=/bin/sh  and override any sort of
> > init process, so trying to make the 'cdroot' option secure
> > is obsurd, as there's 10 million other ways to get in if you
> > have direct access to the computer.
> 
> The big difference is that init=/bin/sh does not give you a normal working 
> system, cdboot however could be abused to get a normal functioning 
> passwordless console. That would allow incapable systemadmins to decide to do 
> this, or even tell others to do it (the latter I want to prevent).
> 

Ill post some changes later that may be acceptable in this case.


-- 
Martin Schlemmer
-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-releng] Re: baselayout changes for livecds

[Martin Schlemmer]

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

On Sat, 2004-01-17 at 06:23, Brad House wrote:
> Ok, these are the necessary changes I've made to baselayout
> for livecds.  I've seperated the necessary scripts into a
> /sbin/livecd-functions.sh to keep bloat out of functions.sh and
> rc.  To summarize the changes, it reads  'cdroot' and 'console' off
> the commandline, and it exports $CDBOOT if cdroot is set, and
> spawns the proper getty (by rewriting inittab) as specified by
> the console command line passed to the kernel (if none is passed,
> default ttys are used, and uses auto-login).
> 
> 2 patches here.
> - 1 to baselayout's ebuild to make sure /sbin/livecd-functions.sh
> is installed.
> - 1 to rc-scripts to add livecd functionality.
> 

There are some fluff in baselayout ebuild not needed.  I will
let you know what after I have worked through it.  Also, I still
think we should have USE=livecd to even install livecd related
scripts, etc - more after review.

> 
> TODO (in baselayout):
> - autogen random password on boot, for security

I think the general idea is not to have a passwd with
a livecd - just me though.

> - fix misc bootsplash stuff (not livecd related)
> 

Right.  Did anybody yet fix the damn bootsplash ebuild to
actually work with the new baselayout?

> PS: these fixes are very non-intrusive, please apply asap.
> 

I do not see the rush - all who is appropriate, can get things
done for the time being, but I really want a few days to sit
and sort through this.


Thanks,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: baselayout changes for livecds

[John Davis]

>I do not see the rush - all who is appropriate, can get things
>done for the time being, but I really want a few days to sit
>and sort through this.
>
>
>Thanks,
>
>  
>
Azarah:
There is in fact a need for the rush. We cannot release 2004.0 until 
these baselayout fixes are applied. I understand that you are concerned 
about QA (and so are we), but you must understand that these patches are 
of the utmost importance. The patches do not seem to be overly 
intrusive, and I have seen some good ideas to fix the only controversial 
part (the CDBOOT stuff). If you need to incorporate a USE flag, then 
please do so. Realistically, we need to see these patches in a stable 
baselayout by mid next week. Thanks Azarah.

Cheers,
//zhen

--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Daniel Robbins]

On Sat, 2004-01-17 at 15:53, Martin Schlemmer wrote:
> Point I wanted to make, was that you do not need whatever in a stable
> baselayout, as it _only_ affects the livecd, or do I miss something?

It looks like Brad found a good workaround for this. We can unmask the
baselayout we need (-r4) in our catalyst portage snapshot, and force a
re-merge of baselayout on the livecd by listing it in livecd/packages:
in the catalyst spec file.

And in hindsight, I guess it's good that our baselayout is masked -* for
now, as we may need additional fixes in the coming week or two and may
not want to keep pushing out new stable baselayouts every few days just
for livecd stuff.

Sorry for any pushiness from us; we've been working extra-hard on
catalyst and we can become frantic because of our desire to have 
catalyst livecds work for people asap -- which then opens up the
possibility of sleeping more, catching up on other important work, and
having a real life again :) A lot of it is also that we know that other
people are waiting for us, which puts pressure on us to work too hard --
and then we start demanding that from others which isn't fair, or in
this case even necessary.

For 2004.0, our deadline needs to be "as soon as possible --  without
working too hard, being too pushy, getting frantic or burning out." And
in that, we will try to do a better job.

Best Regards,

Daniel



--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Martin Schlemmer]

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

On Sun, 2004-01-18 at 07:24, Daniel Robbins wrote:
> On Sat, 2004-01-17 at 15:53, Martin Schlemmer wrote:
> > Point I wanted to make, was that you do not need whatever in a stable
> > baselayout, as it _only_ affects the livecd, or do I miss something?
> 
> It looks like Brad found a good workaround for this. We can unmask the
> baselayout we need (-r4) in our catalyst portage snapshot, and force a
> re-merge of baselayout on the livecd by listing it in livecd/packages:
> in the catalyst spec file.
> 
> And in hindsight, I guess it's good that our baselayout is masked -* for
> now, as we may need additional fixes in the coming week or two and may
> not want to keep pushing out new stable baselayouts every few days just
> for livecd stuff.
> 
> Sorry for any pushiness from us; we've been working extra-hard on
> catalyst and we can become frantic because of our desire to have 
> catalyst livecds work for people asap -- which then opens up the
> possibility of sleeping more, catching up on other important work, and
> having a real life again :) A lot of it is also that we know that other
> people are waiting for us, which puts pressure on us to work too hard --
> and then we start demanding that from others which isn't fair, or in
> this case even necessary.
> 
> For 2004.0, our deadline needs to be "as soon as possible --  without
> working too hard, being too pushy, getting frantic or burning out." And
> in that, we will try to do a better job.
> 

Ok, what about catalist install its own version of livecd-functions.sh
for the moment, with the ebuild only when USE=livecd.  We then change
the bit for sourcing livecd-functions.sh in /sbin/rc to:

--
--- rc-scripts-1.4.3.12p2/sbin/rc       2003-12-25 19:25:24.000000000 -0500
+++ rc-scripts-1.4.3.12p5/sbin/rc       2004-01-16 23:10:40.880824792 -0500
@@ -6,6 +6,7 @@
                                                                                                                             
 trap ":" INT QUIT TSTP
 source /sbin/functions.sh
+[ -f /sbin/livecd-functions.sh ] && source /sbin/livecd-functions.sh
 umask 022
                                                                                                                             
 try() {
@@ -163,6 +164,11 @@
--

Meaning any of the livecd changes will _only_ be available on a livecd,
which cuts the uneeded overhead, and settles Paul's concerns?  When
USE=livecd then propagated, catalyst can then stop installing its own
version ...


-- 
Martin Schlemmer
-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: baselayout changes for livecds

[Brad House]

yes that would work, but drobbins already expressed a concern with
USE=livecd   Since we base our livecds off of a stage3 which would
NOT have USE=livecd, we have to reemerge baselayout.  I don't believe
catalyst is capable of reemerging the same package that already exists
on the system without hacking it up some, so the easier way around would
be to make everyone bump the baselayout -rN and resnap the portage tree
and make it depend on that version of baselayout.  Just another
step which the whole point to catalyst was to have everything in portage
and easy to use so general users could create their own livecds with
their own apps, etc.
It is a solution, just not the best at this point :/
I still don't see the security concern though, but perhaps I'm
thick headed.

> Ok, what about catalist install its own version of livecd-functions.sh
> for the moment, with the ebuild only when USE=livecd.  We then change
> the bit for sourcing livecd-functions.sh in /sbin/rc to:
>
> --
> --- rc-scripts-1.4.3.12p2/sbin/rc       2003-12-25 19:25:24.000000000
> -0500
> +++ rc-scripts-1.4.3.12p5/sbin/rc       2004-01-16 23:10:40.880824792
> -0500
> @@ -6,6 +6,7 @@
>
>  trap ":" INT QUIT TSTP
>  source /sbin/functions.sh
> +[ -f /sbin/livecd-functions.sh ] && source /sbin/livecd-functions.sh
>  umask 022
>
>  try() {
> @@ -163,6 +164,11 @@
> --
>
> Meaning any of the livecd changes will _only_ be available on a livecd,
> which cuts the uneeded overhead, and settles Paul's concerns?  When
> USE=livecd then propagated, catalyst can then stop installing its own
> version ...
>
>
> --
> Martin Schlemmer
> --
>
> Martin Schlemmer
> Gentoo Linux Developer, Desktop/System Team Developer
> Cape Town, South Africa
>
>
>


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Martin Schlemmer]

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

On Sun, 2004-01-18 at 18:42, Brad House wrote:
> yes that would work, but drobbins already expressed a concern with
> USE=livecd   Since we base our livecds off of a stage3 which would
> NOT have USE=livecd, we have to reemerge baselayout.  I don't believe
> catalyst is capable of reemerging the same package that already exists
> on the system without hacking it up some, so the easier way around would
> be to make everyone bump the baselayout -rN and resnap the portage tree
> and make it depend on that version of baselayout.  Just another
> step which the whole point to catalyst was to have everything in portage
> and easy to use so general users could create their own livecds with
> their own apps, etc.
> It is a solution, just not the best at this point :/
> I still don't see the security concern though, but perhaps I'm
> thick headed.
> 

Well, you cannot expect anything to just fall into place if you drop
this on me right now, and say 'it have to be fixed right now'.  How
long have work for catalyst been going?  Why didn't you involve me
sooner if you _knew_ there would be baselayout changes?

I already stepped back a bit, but I do _not_ see why the livecd stuff
should be overhead for all users, if it will be like 1 out of a 1000
times actually for startups out there.  Is it _really_ that much to
ask catalyst to just install /sbin/livecd-functions.sh if not present
at the end of stage3 unpack?

> > Ok, what about catalist install its own version of livecd-functions.sh
> > for the moment, with the ebuild only when USE=livecd.  We then change
> > the bit for sourcing livecd-functions.sh in /sbin/rc to:
> >
> > --
> > --- rc-scripts-1.4.3.12p2/sbin/rc       2003-12-25 19:25:24.000000000
> > -0500
> > +++ rc-scripts-1.4.3.12p5/sbin/rc       2004-01-16 23:10:40.880824792
> > -0500
> > @@ -6,6 +6,7 @@
> >
> >  trap ":" INT QUIT TSTP
> >  source /sbin/functions.sh
> > +[ -f /sbin/livecd-functions.sh ] && source /sbin/livecd-functions.sh
> >  umask 022
> >
> >  try() {
> > @@ -163,6 +164,11 @@
> > --
> >
> > Meaning any of the livecd changes will _only_ be available on a livecd,
> > which cuts the uneeded overhead, and settles Paul's concerns?  When
> > USE=livecd then propagated, catalyst can then stop installing its own
> > version ...
> >
> >
> > --
> > Martin Schlemmer
> > --
> >
> > Martin Schlemmer
> > Gentoo Linux Developer, Desktop/System Team Developer
> > Cape Town, South Africa
> >
> >
> >
> 
> 
> --
> gentoo-releng@gentoo.org mailing list
-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: baselayout changes for livecds

[Brad House]

>
> Well, you cannot expect anything to just fall into place if you drop
> this on me right now, and say 'it have to be fixed right now'.  How
> long have work for catalyst been going?  Why didn't you involve me
> sooner if you _knew_ there would be baselayout changes?

This was all just thrown on me last week, and with the release
pending, I worked my ass off to get it all done. Baselayout was
a very small part of all of that.  Drobbins did a good job getting
catalyst done, but a lot was left up to me with the rest of the
system, and tweaking some things in catalyst to be more friendly.
Please don't act like it's just you stressed for time, you have no
clue.  I've worked more on Gentoo this week than I have my normal
job. I don't know how I could have possibly notified you sooner.

>
> I already stepped back a bit, but I do _not_ see why the livecd stuff
> should be overhead for all users, if it will be like 1 out of a 1000
> times actually for startups out there.  Is it _really_ that much to
> ask catalyst to just install /sbin/livecd-functions.sh if not present
> at the end of stage3 unpack?

Yes, we can make catalyst distribute that, but it's not organized
to do that at all, catalyst is really only meant to distribute what
is in a portage tree. Which is the opposite mentality from the previous
livecd scripts.  Again, it's hackish, and if I remember correctly,
drobbins specifically forbids doing that. So we'd have to make a
baselayout-livecd.ebuild or something to keep it in line.

At this point though, I'm stepping back. I've provided the necessary
changes, it's up to someone else to determine how to use and distribute
them.  I'm not a fan of bureaucracy, and don't deal with it well.

-Brad

--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Martin Schlemmer]

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

On Sun, 2004-01-18 at 18:42, Brad House wrote:
> yes that would work, but drobbins already expressed a concern with
> USE=livecd   Since we base our livecds off of a stage3 which would
> NOT have USE=livecd, we have to reemerge baselayout.  I don't believe
> catalyst is capable of reemerging the same package that already exists
> on the system without hacking it up some, so the easier way around would
> be to make everyone bump the baselayout -rN and resnap the portage tree
> and make it depend on that version of baselayout.  Just another
> step which the whole point to catalyst was to have everything in portage
> and easy to use so general users could create their own livecds with
> their own apps, etc.

Oh, and I never said you had to remerge baselayout - but come to think
of it, you are right, it will have to be done so.  But it will have to
be done so anyhow.

So I do propose that catalyst rather install livecd-functions.sh by
itself, as it will:
1) Not need a remerge
2) Keep livecd-functions.sh seperate, so future fixes will not need
   a baselayout bump, but just an catalyst one.

> It is a solution, just not the best at this point :/
> I still don't see the security concern though, but perhaps I'm
> thick headed.
> 
> > Ok, what about catalist install its own version of livecd-functions.sh
> > for the moment, with the ebuild only when USE=livecd.  We then change
> > the bit for sourcing livecd-functions.sh in /sbin/rc to:
> >
> > --
> > --- rc-scripts-1.4.3.12p2/sbin/rc       2003-12-25 19:25:24.000000000
> > -0500
> > +++ rc-scripts-1.4.3.12p5/sbin/rc       2004-01-16 23:10:40.880824792
> > -0500
> > @@ -6,6 +6,7 @@
> >
> >  trap ":" INT QUIT TSTP
> >  source /sbin/functions.sh
> > +[ -f /sbin/livecd-functions.sh ] && source /sbin/livecd-functions.sh
> >  umask 022
> >
> >  try() {
> > @@ -163,6 +164,11 @@
> > --
> >
> > Meaning any of the livecd changes will _only_ be available on a livecd,
> > which cuts the uneeded overhead, and settles Paul's concerns?  When
> > USE=livecd then propagated, catalyst can then stop installing its own
> > version ...
> >
> >
> > --
> > Martin Schlemmer
> > --
> >
> > Martin Schlemmer
> > Gentoo Linux Developer, Desktop/System Team Developer
> > Cape Town, South Africa
> >
> >
> >
-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: baselayout changes for livecds

[Daniel Robbins]

On Sun, 2004-01-18 at 10:34, Martin Schlemmer wrote:
> So I do propose that catalyst rather install livecd-functions.sh by
> itself, as it will:
> 1) Not need a remerge
> 2) Keep livecd-functions.sh seperate, so future fixes will not need
>    a baselayout bump, but just an catalyst one.

OK, let's support a USE="livecd" but *only* for baselayout at this point
(don't want it to be used for other ebuilds for 2004.0.) If
USE="livecd", then livecd-functions.sh gets installed. And you can add a
"[ -f livecd-functions.sh ] && source" conditional.

Will that work for everyone? Please? :)

Regards,

Daniel



--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Brad House]

will catalyst reemerge a package that is already installed
if you list it on  livecd/packages  ?
if not, it's going to need to for this to work.

-Brad

> On Sun, 2004-01-18 at 10:34, Martin Schlemmer wrote:
>> So I do propose that catalyst rather install livecd-functions.sh by
>> itself, as it will:
>> 1) Not need a remerge
>> 2) Keep livecd-functions.sh seperate, so future fixes will not need
>>    a baselayout bump, but just an catalyst one.
>
> OK, let's support a USE="livecd" but *only* for baselayout at this point
> (don't want it to be used for other ebuilds for 2004.0.) If
> USE="livecd", then livecd-functions.sh gets installed. And you can add a
> "[ -f livecd-functions.sh ] && source" conditional.
>
> Will that work for everyone? Please? :)
>
> Regards,
>
> Daniel
>
>
>
>


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Martin Schlemmer]

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

On Mon, 2004-01-19 at 23:39, Daniel Robbins wrote:
> On Sun, 2004-01-18 at 10:34, Martin Schlemmer wrote:
> > So I do propose that catalyst rather install livecd-functions.sh by
> > itself, as it will:
> > 1) Not need a remerge
> > 2) Keep livecd-functions.sh seperate, so future fixes will not need
> >    a baselayout bump, but just an catalyst one.
> 
> OK, let's support a USE="livecd" but *only* for baselayout at this point
> (don't want it to be used for other ebuilds for 2004.0.) If
> USE="livecd", then livecd-functions.sh gets installed. And you can add a
> "[ -f livecd-functions.sh ] && source" conditional.
> 
> Will that work for everyone? Please? :)
> 

Yep.  Sorry, but I am just anti-bloat in baselayout =)  Brad do have a
point though - can catalyst remerge baselayout?  Or can it rather
install livecd-functions.sh.  I am not sure about the 'hack' level that
will be (as Brad keeps calling it), but then I have not had a chance to
look at catalyst as of yet.


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: baselayout changes for livecds

[Daniel Robbins]

On Mon, 2004-01-19 at 21:40, Martin Schlemmer wrote:
> Yep.  Sorry, but I am just anti-bloat in baselayout =)  Brad do have a
> point though - can catalyst remerge baselayout?  Or can it rather
> install livecd-functions.sh.  I am not sure about the 'hack' level that
> will be (as Brad keeps calling it), but then I have not had a chance to
> look at catalyst as of yet.

Shouldn't be a problem.

Regards,

Daniel


--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: baselayout changes for livecds

[Martin Schlemmer]

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

On Tue, 2004-01-20 at 21:20, Daniel Robbins wrote:
> On Mon, 2004-01-19 at 21:40, Martin Schlemmer wrote:
> > Yep.  Sorry, but I am just anti-bloat in baselayout =)  Brad do have a
> > point though - can catalyst remerge baselayout?  Or can it rather
> > install livecd-functions.sh.  I am not sure about the 'hack' level that
> > will be (as Brad keeps calling it), but then I have not had a chance to
> > look at catalyst as of yet.
> 
> Shouldn't be a problem.
> 

Ok, -r5 is in the tree, please check, and let me know if anything more
is needed.  I masked it for now, but we can undo that as soon as we get
a go.


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: baselayout changes for livecds

[Martin Schlemmer]

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

On Wed, 2004-01-21 at 21:12, Martin Schlemmer wrote:
> On Tue, 2004-01-20 at 21:20, Daniel Robbins wrote:
> > On Mon, 2004-01-19 at 21:40, Martin Schlemmer wrote:
> > > Yep.  Sorry, but I am just anti-bloat in baselayout =)  Brad do have a
> > > point though - can catalyst remerge baselayout?  Or can it rather
> > > install livecd-functions.sh.  I am not sure about the 'hack' level that
> > > will be (as Brad keeps calling it), but then I have not had a chance to
> > > look at catalyst as of yet.
> > 
> > Shouldn't be a problem.
> > 
> 
> Ok, -r5 is in the tree, please check, and let me know if anything more
> is needed.  I masked it for now, but we can undo that as soon as we get
> a go.

Is -r5 ok?



-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-releng] Re: baselayout changes for livecds

[Daniel Robbins]

On Sat, 2004-01-17 at 15:11, Martin Schlemmer wrote:
> There are some fluff in baselayout ebuild not needed.  I will
> let you know what after I have worked through it.  Also, I still
> think we should have USE=livecd to even install livecd related
> scripts, etc - more after review.

Catalyst builds livecds using standard stage3 tarballs, and a USE=livecd
would require baselayout to be re-merged on the livecd, as well as any
other packages that start using the "livecd" USE variable. For now, this
is a bad idea since our efforts have been focused on building up LiveCDs
from stage3's, not stage2's. For this release cycle, we're going to
start with a stage3.

USE=livecd is something we can explore for 2004.1, but it doesn't work
for us now, particularly for packages that are already merged in a
stage3.

> > TODO (in baselayout):
> > - autogen random password on boot, for security
> 
> I think the general idea is not to have a passwd with
> a livecd - just me though.

The best way to set up sshd on the livecd is to allow root logins, but
randomize the root password for security. Then the user just needs to
use "passwd" to set a new root password rather than edit
/etc/sshd/sshd_config to allow root login, restart the daemon *and* run
passwd.

> > PS: these fixes are very non-intrusive, please apply asap. 
> 
> I do not see the rush - all who is appropriate, can get things
> done for the time being, but I really want a few days to sit
> and sort through this.

Brad is requesting for this to happen quickly because other people (in
fact, the entire Gentoo LiveCD development effort) is waiting for these
fixes to get into baselayout. Showing some concern for our schedule
would be greatly appreciated.

Regards,

Daniel


--
gentoo-releng@gentoo.org mailing list