Horms
2005-Dec-01 00:33 UTC
[Xen-devel] [PATCH] 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 <horms@verge.net.au> # 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 <horms@verge.net.au 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." _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Robert Read
2005-Dec-01 05:40 UTC
Re: [Xen-devel] [PATCH] install.sh: install as root with reasonable permissions
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 On Nov 30, 2005, at 16:33, Horms wrote:> 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 <horms@verge.net.au> > # 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 <horms@verge.net.au > > 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." > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Horms
2005-Dec-01 06:04 UTC
[Xen-devel] Re: [PATCH] install.sh: install as root with reasonable?permissions
Robert Read <robert@xensource.com> wrote:> 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?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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Emmanuel Ackaouy
2005-Dec-15 18:03 UTC
Re: [Xen-devel] Re: [PATCH] install.sh: install as root with reasonable permissions
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 ... 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? Cheers, Emmanuel.> From: Horms <horms@verge.net.au> > [...] > I played around with a few other ideas and I think that the /tmp option > is a clean and easy solution. Here is a patch that does this. > > # HG changeset patch > # User Horms <horms@verge.net.au> > # Node ID 651f32f67427ebb167eb2b6d921182bb21da2a7b > # Parent 340bec28050f360b9d800fb354abfd6b5ee80bd2 > [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@verge.net.au> > > diff -r 340bec28050f -r 651f32f67427 install.sh > --- a/install.sh Fri Dec 2 02:16:21 2005 > +++ b/install.sh Fri Dec 2 02:21:15 2005 > @@ -22,19 +22,25 @@ > 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 - > +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/ > + cp -f $src/etc/udev/rules.d/*.rules "$tmp/etc/udev/rules.d/" > else > - cp -f $src/etc/hotplug/*.agent $dst/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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Horms
2005-Dec-16 02:18 UTC
Re: [Xen-devel] Re: [PATCH] install.sh: install as root with reasonable permissions
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 existThanks, 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@verge.net.au> # 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@verge.net.au> 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@lists.xensource.com http://lists.xensource.com/xen-devel