On Fri, Oct 05, 2007 at 01:17:44AM -0400, Phil Light wrote:
Hello, thank you so much for working on debian-live. It's vastly
improved my release process, now that I have it set up.
Hi Phil,
I had some comments.
You say to use visudo but then to remove the .tmp extension.
Actually you should *not* remove the .tmp. I'm fairly certain that
what's happens is:
lock /etc/sudoers
copies sudoers to sudoers.tmp
/usr/bin/editor /etc/sudoers.tmp
ret=0
diff /etc/sudoers /etc/sudoers.tmp || ret=$?
case $ret in
0) echo Not changed 2 exit 0;;
1) exec mv /etc/sudoers.tmp /etc/sudoers;;
*) exit 1; # error
esac
The important thing here is that mv is guaranteed to be atomic (if
it succeeds fail) when the dst file is on the same filesystem as the
src, which is guaranteed to be true when they're in the same directory
(or a subdirectory created by the process without mounts).
OTOH if the editor saves to sudoers, it's likely to do just
open(); for(;;){write()}; close(); which means that during some
interval there's an incomplete sudoers file. In the case of sudoers,
it's a security thing even, since the incomplete file can have valid
syntax. In particular if there's an incomplete command specified (ls
is written but it's supposed to be lspci) or a command whose arguments
haven't been written yet (which means any arguments are to be allowed)
or a command with [^ ]* argument (which means extra args are allowed
to eg. passwd).
You said that sudo was subly different from su but the critical thing
is that all your user ID's (IIRC: EUID, RUID, FSUID, SSUID) are set to
0 which happens for both. The differences that I can think of:
sudo sets some environment variables (like SUDO_USER)
su waits for the shell to exit instead of just doing exec(/bin/sh)
so that it can write an pam_end() entry.
normal sudo things: it logs commands, doesn't require disclosing the
root pw, allows multiple commands to be run without starting an
interactive root shell, but times out after a matter of 10 minutes
(Debian changes the default)
You did mv etc/init.d/bittorent graveyard/ but update-rc.d says that
this should be something more elaborate. Either update-rc.d remove,
then stop, or something like:
for s in $srv_disable
do
for f in etc/rc?.d/S[0-9][0-9]$s
do
[ -f $f ] || continue
dir=${f%/*}
mv $f $dir etc/rc$g.d/K$s
done
done
You suggested apt-get remove and dpkg --purge. There's also aptitude
purge and apt-get --purge remove as well as aptitude [install|remove]
foo_ (foo- means remove, foo_ means purge). There *was* a bug in
aptitude which prevented it from purging a package which was removed
(in state config-files) but I think this might have been fixed, but I
also can't find the bug.
Justin
___
debian-live-devel mailing list
debian-live-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
