WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: [PATCH] install.sh: install as root with reasonable?permissions
From: Horms <horms@xxxxxxxxxxxx>
Date: Thu, 1 Dec 2005 06:04:46 +0000 (UTC)
Delivery-date: Thu, 01 Dec 2005 06:06:33 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <dmlgd4$u1l$1@xxxxxxxxxxxxx> <9095E0DE-AE2B-4560-8CF7-F0C8DBC32F2C@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: tin/1.7.10-20050815 ("Grimsay") (UNIX) (Linux/2.6.12.6-xen0 (i686))
Robert Read <robert@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>