linux-kernel - Re: script relative shebang

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9d6adc59-3893-18f9-c003-c54a1db9e3cc@gmail.com>
Date:	Wed, 1 Jun 2016 11:38:59 -0400
From:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>
To:	Boris <ribalkin@...il.com>
Cc:	Nicolai Stange <nicstange@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: script relative shebang

On 2016-06-01 04:00, Boris wrote:
> Hi Nicolai,
>
> Yes, I think this is too ugly:
>
> #!/usr/bin/gawk {exit system("/bin/sh -c 'exec \"$(dirname \"$0\")\"/subdir/catself \"$0\"' " FILENAME);}
>
> Imagine you have that feature in your kernel would you rather use:
>
> #!{dirname}/subdir/catself
The problem with using a keyword is that current VFS standards on Linux 
mean that most filesystems that are native to Linux support _any_ 
character in a path name component except for a null byte.  Because of 
that, you can't from a practical perspective choose a keyword that is 
guaranteed to not clash with any path name, unless you want a 256 
character long keyword (which would be worse than the current option).
>
> You second advice involves changing root fs which is not desirable in copy-deployment apps (bring all the dependencies)
Not necessarily, include the wrapper in the app itself.  It's not hard 
even in shell script to figure out where you're being run from, so it's 
really not all that hard to handle this.

In bash, you can do the following in a script to get the canonical path 
to you're script (in an interactive shell, it will just point you at the 
bash executable):
SELF=$_
SELF=$(realpath ${SELF})

This only works if it's done at the top level of a script (not within a 
function).

If you go with the wrapper option, you can find your canonical path name 
in /proc/self/exe (note that this won't work right when doing something 
like `readlink /proc/self/exe` from an interpreter, as that will return 
the path to readlink), or just look up your PID and check /proc/PID/exe.

Also, the convention for such things on most UNIX like systems is to 
install wrappers, often using symlinks, in some location that is listed 
in $PATH.  For example, on many Linux systems, Dropbox gets installed 
into /opt/dropbox, and then a link for it is created in /opt/bin to 
point at the core program itself.  If it's a GUI only app, you could 
also just use .desktop files to point at the tools instead of symlinks, 
Google Chrome does this for example.

Using the bash example above, the following snippet could be used as a 
wrapper by placing it the top level directory of the above example and 
then symlinking to it from somewhere in $PATH:

#!/bin/bash
SELF=$_
SOURCE=$(dirname $(realpath ${SELF}))
exec ${SOURCE}/subdir/catself $@

You could then use that script as your interpreter.