Re: [Xen-devel] Re: [PATCH] install.sh: install as root with reasonable permissions

[Horms <horms@xxxxxxxxxxxx>]

On Thu, Dec 15, 2005 at 06:03:20PM +0000, Emmanuel Ackaouy wrote:
> 
> There are some problems with this patch as applied on top
> of the unstable tree.
> 
> Recursive cp's into non-existing subdirs of the tmp
> directory fail:
> 
> Installing Xen from './install' to '/'...
> cp: `/tmp/tmp.RMnWQq3560/etc/init.d/': specified destination directory does 
> not exist

Thanks, I believe the updated patch below addresses that concern.

> For the patch to work, we'd also need to "mkdir -p" any directory
> which is the destination of a "cp" into the tmp dir.
> 
> 
> I'm also confused about the bug to start with:
> 
> As far as I can see, all Makefiles in the repository install
> files into dist/install using /usr/bin/install with properly
> set permissions. If one does not, then that would be a bug
> and we ought to fix it. /usr/bin/install should also create
> parent directories with appropriate permissions. The umask
> of the person running the build should have no effect. Have I
> missed something? Which files under /lib did you find created
> with bad permissions? Perhaps this is a problem with the linux
> build installing modules with permissions based on the umask
> of the build process?

Yes, but the problem is that when they are installed into a local
holding space the permisions can be a bit weird. We considered a few
different options, including making sure they always had the desired
permisions in the local directory.  But as the user might actually want
these permsisions to be a bit odd, and worse still, the permsisions
might get changed between when the files are placed in the local dist
directory, and when install.sh is called. In any case, it seemed better
to fix it at the time the install actually took place.

To be quite honest, I'm not entirely happy with the solution myself.  I
think install.sh should really manage what is installed more
intellegently. And allow for uninstall too. However that is really more
the role of a package manager, this fix does seem to be reasonably clean
and solve the problem at hand farily unintrousively, so I think it is a
good choice, at least for now.

-- 
Horms

# HG changeset patch
# User Horms <horms@xxxxxxxxxxxx>
# Node ID 5487bd2d2bfc01f0b113d410c5923e736be7fa1c
# Parent  9794d56f1b45132d6e3480630d754224cb373814
[INSTALL] Fix owner and permissions for installed files

Make sure that installed files have sensible permissions
and are owned by the user running install, presumably root.

Without this patch, if the user that does the build has
a restrictive umask, say 0077, and the install is done into /,
then /lib, will become only accessable to that user.

Signed-Off-By: Horms <horms@xxxxxxxxxxxx>

diff -r 9794d56f1b45 -r 5487bd2d2bfc install.sh
--- a/install.sh        Fri Dec 16 02:12:45 2005
+++ b/install.sh        Fri Dec 16 02:14:09 2005
@@ -22,19 +22,28 @@
   exit 1
 fi
 
+tmp="`mktemp -d`"
+
 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 -
-cp -fdRL $src/etc/init.d/* $dst/etc/init.d/
+(cd $src; tar -cf - --exclude etc/init.d --exclude etc/hotplug --exclude 
etc/udev * ) | tar -C "$tmp" -xf -
+mkdir -p "$tmp"/etc/init.d/
+cp -fdRL $src/etc/init.d/* "$tmp"/etc/init.d/
 echo "All done."
 
 [ -x "$(which udevinfo)" ] && \
   UDEV_VERSION=$(udevinfo -V | sed -e 's/^[^0-9]* 
\([0-9]\{1,\}\)[^0-9]\{0,\}/\1/')
 
 if [ -n "$UDEV_VERSION" ] && [ $UDEV_VERSION -ge 059 ]; then
-  cp -f $src/etc/udev/rules.d/*.rules $dst/etc/udev/rules.d/
+  mkdir -p "$tmp/etc/udev/rules.d/"
+  cp -f $src/etc/udev/rules.d/*.rules "$tmp/etc/udev/rules.d/"
 else
-  cp -f $src/etc/hotplug/*.agent $dst/etc/hotplug/
+  mkdir -p "$tmp/etc/hotplug/"
+  cp -f $src/etc/hotplug/*.agent "$tmp/etc/hotplug/"
 fi
+
+chmod -R a+rX "$tmp"
+(cd $tmp; tar -cf - *) | tar --no-same-owner -C "$dst" -xf -
+rm -r "$tmp"
 
 echo "Checking to see whether prerequisite tools are installed..."
 cd $src/../check

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel