Source file permissions are not safe

[guanx]

The source files are owned by a normal user. When root unpacks the tar ball to some public place, e.g. /usr/src or /tmp, normal users may have write access to the source.

To correct this, run the following command before packing the source code for publication:

chown -R root:root mc-x.y.z
chmod -R og-w mc-x.y.z

[styx]

It is normal, that users can compile something they want. If this is problem for root user, he should do that on his own way...

[slavazanko]

Please, don't compile under user root.

Safe guideline for compile and install mc (and for many others autotools-based):

$ [./autogen.sh] # if needed
$ ./configure --prefix=/prefix/to
$ make
$ mkdir -p ~/FAKE_ROOT
$ make install DESTDIR=~/FAKE_ROOT
review at this stage ~/FAKE_ROOT
$ su -
# cp -fR /home/builder/FAKE_ROOT/* /

[guanx]

Replying to slavazanko:

Please, don't compile under user root.

Safe guideline for compile and install mc (and for many others autotools-based):

$ [./autogen.sh] # if needed
$ ./configure --prefix=/prefix/to
$ make
$ mkdir -p ~/FAKE_ROOT
$ make install DESTDIR=~/FAKE_ROOT
review at this stage ~/FAKE_ROOT
$ su -
# cp -fR /home/builder/FAKE_ROOT/* /

This can surely workaround the defect. However, this method is not mentioned in the standard INSTALL file came from autotools. The usual way of installation, which is, I believe, followed by most users, is the three steps of ./configure, make, and make install.

A security hole can be worked around does not mean that it needs no fixing. Nearly all security holes have no harm if you run the affected software in a virtual machine. Then shall we not fix any of them?

I admit that this permission problem will not affect experienced users. But by improving the software, we can put less users under risk.

An example of this permission change is: The Linux kernel was distributed with similar ownership/permissions as mc is, but now all files in the Linux source archive is owned by root, and the write permissions by group and others are removed.

[winnie]

Replying to guanx:

This can surely workaround the defect. However, this method is not mentioned in the standard INSTALL file came from autotools. The usual way of installation, which is, I believe, followed by most users, is the three steps of ./configure, make, and make install.

The common way is (as user): ./configure; make
then as superuser: make install

A security hole can be worked around does not mean that it needs no fixing. Nearly all security holes have no harm if you run the affected software in a virtual machine. Then shall we not fix any of them?

I admit that this permission problem will not affect experienced users. But by improving the software, we can put less users under risk.

An example of this permission change is: The Linux kernel was distributed with similar ownership/permissions as mc is, but now all files in the Linux source archive is owned by root, and the write permissions by group and others are removed.

A normal user should be able to compile a program.. the kernel is something
different... so please don't compare with the kernel but with other userspace
tools, e.g. openssh, firefox/iceweasel, bkchem, .... 1000 others.

Userspace tools should be compileable and modifieable by normal users and not
only by the superuse.. so sorry this is a wontfix for me.. and I guess for the
others.

Greetings
Winnie

[anonymous]

Milestone 4.6.3 deleted