From: Horms <horms@verge.net.au>
To: xen-devel@lists.xensource.com
Subject: Re: [PATCH] install.sh: install as root with reasonable?permissions
Date: Thu, 1 Dec 2005 06:04:46 +0000 (UTC) [thread overview]
Message-ID: <dmm3pu$hqd$1@sea.gmane.org> (raw)
In-Reply-To: 9095E0DE-AE2B-4560-8CF7-F0C8DBC32F2C@xensource.com
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
next prev parent reply other threads:[~2005-12-01 6:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-01 0:33 [PATCH] install.sh: install as root with reasonable permissions Horms
2005-12-01 5:40 ` Robert Read
2005-12-01 6:04 ` Horms [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-12-01 13:58 [PATCH] install.sh: install as root with reasonablepermissions Ian Pratt
2005-12-02 2:25 ` [PATCH] install.sh: install as root with reasonable permissions Horms
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='dmm3pu$hqd$1@sea.gmane.org' \
--to=horms@verge.net.au \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.