install.sh: install as root with reasonable permissions

Hi,

The topic of creating uninstall.sh came up recently, so I though I'd throw this install.sh patch into the ring.

I noticed when running install.sh as non-root with a custom umask of 0077, that amongst other things /lib becamed owned by my userid with mode 0700. Which was not an entirley expected or desirable outcome.

The patch below attempts to make install.sh install files as root, with the permisions that would be created if umask is 0022. That is, directories are at least mode 755, and files are at least mode 644. Its a bit crude, but seems at the very least to be an improvement on the current situation.

An improvement would be to make sure that files are installed into install/ with the permissions that they should ultimately be installed into /root with. This would require somewhat more extensive changes than the chown effected below.

Horms


# HG changeset patch
# User Horms <[email protected]>
# Node ID 1b6ef5cde5b123b86f1a11f0709d4b1347d47ce1
# Parent  37d3e34dfdac009eac2bb040ff79ae711b2d50f9
Make sure files are installed as root with reasonable permissions

* Fix the permissions in $src, as in some cases,
  particularly in lib and user/lib/python, they will
  have been created with the prevailing umask.
  After install this umask will cover /lib and /usr/lib/python,
  and if the umask is restrictive, this will cause all
  sorts of weird failures.
* Make sure files are installed using tar are installed as root.root

Signed-Off-By: Horms <[email protected]

diff -r 37d3e34dfdac -r 9570d0b15d6e install.sh
--- a/install.sh	Sat Nov 26 11:37:18 2005
+++ b/install.sh	Mon Nov 28 02:56:54 2005
@@ -22,8 +22,11 @@
   exit 1
 fi
 
+echo "Fixing permissions in '$src/lib'"
+find $src | xargs chmod a+rX
+
 echo "Installing Xen from '$src' to '$dst'..."
-(cd $src; tar -cf - --exclude etc/init.d --exclude etc/hotplug --exclude etc/udev * ) | tar -C $dst -xf -
+(cd $src; tar -cf - --owner 0 --group 0 --exclude etc/init.d --exclude etc/hotplug --exclude etc/udev * ) | tar -C $dst -xf -
 cp -fdRL $src/etc/init.d/* $dst/etc/init.d/
 echo "All done."

diff -r 37d3e34dfdac -r 1b6ef5cde5b1 install.sh
--- a/install.sh	Sat Nov 26 11:37:18 2005
+++ b/install.sh	Mon Nov 28 02:58:09 2005
@@ -22,8 +22,11 @@
   exit 1
 fi
 
+echo "Fixing permissions in '$src'"
+find $src | xargs chmod a+rX
+
 echo "Installing Xen from '$src' to '$dst'..."
-(cd $src; tar -cf - --exclude etc/init.d --exclude etc/hotplug --exclude etc/udev * ) | tar -C $dst -xf -
+(cd $src; tar -cf - --owner 0 --group 0 --exclude etc/init.d --exclude etc/hotplug --exclude etc/udev * ) | tar -C $dst -xf -
 cp -fdRL $src/etc/init.d/* $dst/etc/init.d/
 echo "All done."

Currently install.sh doesn't change the source tree, which is a good thing. This allows it to be run by root when the tree is on a root squashing NFS export. If the permissions need fixing, can we doing it during the build instead?

cheers,
robert

I wasn't entirely happy with the in-tree change either, thanks for a reasonable case where it is the wrong thing to do. I have serveral ideas on how to get around it:

1. Make sure the files in install/ always have the permissions they should be installed with. This could be done several ways, most trivially by just chowning install/dist/ after putting the files in there.

However, might not be desirable, say if for some reason the files in the working directory really should have restrictive permissions to avoid unwanted prying eyes. Though to be fair, its no worse than my current patch.

2. I think this is my prefered option

Create a list of files that are to be installed, this could be done by the target that places files into install (say by using find after putting them there). We probably need such a list if uninstall.sh was to materialise.

Then, install.sh copies files into / it could run through that list, and update the permissions on the files and directories accordingly. The list could include permissions which would allow non-standard permissions to be used as needed, say for instance /var/lib/fobar is actually supposed to be world writable for some obscure reason.

3. Copy the files to some intermediate location and change the permisions using a gratuitous find | xargs chmod, like my patch does in install/ Its not a trememdous ammount of data, so that shouldn't be too bad. But, where to copy?

4. Change the permissions in-flight. I tried getting tar to do this, but it didn't want to play ball. And in any case its not very flexible and is really just a variation on 2), albeit with less work on our parts.

As for if it needs to be done or not. Well, I could be wrong, but I'm pretty sure the following results in a farily broken system, and I'm pretty sure it shouldn't.

# as non-root
umask 0077
make world
sudo ./install.sh
ls -ld /lib /lib/python

Horms