Aggressive chown

[ayeganov]

A few minutes ago my system became practically unusable due to the fact that "chown/chmod" changed permissions on every file on my system. I needed to extract files to a particular location in /etc directory. When I ran the test script with sudo permissions I expected the sudo to be used for writing to the target directory, not to change ownership of files completely unrelated to what I was doing. I suggest to change the default behavior of the script to NOT change ownership of any files unless the user sets a flag to do that explicitly.

[megastep]

Is this an archive you had created yourself or you obtained from somewhere else?

In any case, our usage of chmod is relatively conservative, it's chown that could be a source of problems. The current version of Makeself has a --nochown command line option to disable that behavior.

[ayeganov]

It is an archive I created myself when I was trying to get acquainted with makeself. I reproduced the directory structure of "/etc/init.d/<my_file>" in order for the file to be dropped exactly where I needed it. I found the option --nochown after it was already too late, because I didn't expect it to be used at all. What I am suggesting is to invert the option --nochown to --chown, so in cases like mine, the script wouldn't destroy the system.

[dodtsair]

Same thing happened to me.

I did the following

1. makeself . pacman.run "Pacman as a secondary package manager" echo "Pacman has extracted itself"
2. sudo ./pacman.run --target /

This did almost what I expected, it put the pacman binary in /usr/local/bin/
$ ls /usr/local/bin/pacman /usr/local/bin/pacman

But it also change the ownership of all files on the system.
$ ls -ld ~ drwxr-xr-x 4 root root 4096 Mar 30 15:43 /home/michaelpower

I recommend that makeself should only chown files it itself is putting down.

[dodtsair]

FYI system was Ubuntu 14.04

[megastep]

Yeah, obviously Makeself was never intended to be a mechanism to install system files! Its main purpose is to package self-contained files, including a possible installer that may able to handle this kind of situation more appropriately.

[dodtsair]

Can --nochown and --chown be added as options to makeself.sh the self-extracting archive respectively, allowing users to decide the default behavior the of the self-extracting archive? Also adding --chown to the self extracting archive so users can ask for the chown feature when it is turned off by default?

--nochown : The self-extracting archive will not run a chown -R when running the embedded script after extraction

--chown: Include running a chown -R while running the embedded script to extract the archive

[CarlyAmar]

Seems like even with --nochown, it will still chown the current directory, but not the contents inside of it.

[quinot]

We got bitten by this one, with a deployment script that transferred a Makeself archive generated with --current to a user's home directory, and then executed it from there.

We did this as root on a Solaris machine, where the home dir of root is /. Net result: "chown -R root /", and much havoc in user files.

IMO --nochown should be the default, and a prominent warning should be given for any use of --chown with an existing directory (i.e. --current or --target without --nooverwrite). Running chown -R on a directory when you don't entirely control the contents of that directory is too risky.