Re: Safer package installation
On Sat, 5 Apr 1997, John Foster wrote:
>I see a couple of problems:
>From a users perspective the clourisation option for ls will be close to
>useless, as almost everything under /usr will be pale blue.
Unless you use "ls -L". Not to be pedantic (honest!), but from the
-L If argument is a symbolic link, list the file or direc-
tory the link references rather than the link itself.
Color-ls handles this just the way you'd expect.
>The other one may be just a problem due to my personal laziness. I like
>to take some binaries, mv then to old_name.dist, chmod then to 750 and
>put a little script undr the old name explaining why users can't use
>binaries they expect to be useable (a slightly fascist approach, but at
>least I'm polite enough to let them know why!).
There isn't any reason why this wouldn't work just the same. Symbolic
links reference the file name, so all you need to do is go into
/usr/packages/whatever/bin/ and shuffle the files around as you describe
above. The symbolic link will point to the script. The old file is
right there as /usr/packages/whatever/bin/whateverbin.dist.
>I assume that the /usr/packages/* would be meant to be modified by
>dpkg and the install scripts, and not by me (so as to not break too
Well, actually, one of the benefits of this scheme is that you can do
a fair amount of customization and it's still easy to remove
automatically later. You should be able to do quite a bit under the
package's root directory without mucking up dpkg.
> Symlinks inherit the permissions of the source...
Well, technically, they inherit the logical product of the source's
permissions and the link's permissions. Thus, you can remove
permissions with a link, but not add them. Therefore, the permissions
the users will see will be *at most* 750.
Ray Ingles (810)377-7735 firstname.lastname@example.org
Modern deductive method: 1) Devise hypothesis. 2) Apply for grant.
3) Perform experiments. 4) Revise hypothesis. 5) Backdate revised
hypothesis. 6) Publish.