Self-contained executable for any Linux x86_64 distribution

[Lutz Vieweg]

On 03/03/2013 08:40 PM, Cristian Ionescu-Idbohrn wrote:
>> + D=subsurface
>> + mkdir -p -m 777 /tmp/applink
>> + chmod o+t /tmp/applink

I should probably change this to
   mkdir -p -m 1777 /tmp/applink

> Didn't try your "self-contained" package, as I'm skeptical to that sort of
> thing.  But, Lutz, please try to avoid that sort of thing.  It's the
> classical:
>
> 	http://www.google.com/search?q=insecure+temporary+file

I understand that writing to a file that other users can know
the name of creates a security risk. But how would you exploit
the creation of a symbolic link (that is later used for reading, only)
in a directory with the sticky bit set?

(And my script does verify, after creating the symbolic link,
that this link indeed points to there the script wanted it to point
to - to avoid the race condition that somebody creates a link
before the script does.)

> If you _must_ create a temporary directory, do it under $HOME, and
> absolutely not under /tmp.

The whole point of making that directory is that "/tmp" is the
only constant place in the filesystem that is known to be user-
writeable.

If I create such a directory in $HOME, there is no way to do a
  ./configure --prefix=/tmp/applink/subsurface ...
in preparation for dependencies of the software, because
  ./configure --prefix=/home/*/something
would obviously not be available on the next computer.

> Don't `chmod' anything to permitions 0777 (that's another OSs business).
> 0700 is better.

/tmp/applink/ is meant to contain symbolic links to other applications
(besides subsurface).

> And /tmp is already supposed to have the sticky bit set:
> 	Access: (1777/drwxrwxrwt)

Yes, and I don't see how /tmp/applink creates more of a risk than
/tmp/ itself.

Regards,

Lutz Vieweg