Re: [PATCH] Add a /proc/self/exedir link

Re: [PATCH] Add a /proc/self/exedir link

[Bodo Eggert]

Neil Brown <neilb@suse.de> wrote:
> On Tuesday April 4, mike@plan99.net wrote:

>> To clarify, I'm proposing this patch for eventual mainline inclusion.
>> 
>> It adds a simple bit of API - a symlink in /proc/pid - which makes it
>> easy to build relocatable software:
>> 
>>    ./configure --prefix=/proc/self/exedir/..

[...]

> It strikes me that this is very fragile.  If the application calls
> anything out of /bin or /usr/bin etc passing a path name which works
> for the application, it will break for the helper.

ACK.

> It also requires all binaries use by the application to live in the
> same directory.  This would be OK  for some applications, but not for
> everything.
> 
> It sounds to me like you want a private, inherited, name space, and
> Linux provides those via CLONE_NEWNS, however you probably need root
> access to make that work, which isn't ideal.

This isn't going to rock either. If process A links
$PID->namespace:/const/exedir/ to /mnt/net/host_a/foo/bin and passes
/const/exedir/../lib/foo to process B, this process B must not
link it's $PID->namespace:/const/exedir/ to e.g. /opt/B/bin, but
exactly this is going to happen if you use a constant string.

> I think you'd have move luck (ab)using an environment variable.
> Make
>    /proc/self/env_prefix
> be a symlink pointing to whatever the "PREFIX" environment variable
> stores.

Same problem.


IMO the program must be aware of the get-my-exedir feature, just configuring
--prefix=/proc/... is aiming for your feet.

/proc/pid/exedir may be a way to access the program files after changing the
namespace, but it may also be a security risk leaving the original namespace
accessible. Therefore I suggest abandoning the exedir idea and instead

1) change the programs to be aware of it's exedir:
   (my $exedir=`cat /proc/self/exe`) =~ s,/[^/]+$,,);
   if ($libdir !~ m,^/,) { $libdir = $exedir.'/'.$libdir };
 - or -
   ln -s /mnt/net/host_a/foo /usr/local/foo
   (cd /usr/local/bin && for a in ../foo/bin; do ln -s "$a";done)
2) If you want access across namespaces, use fopen etc. on an open
   directory handle
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: [PATCH] Add a /proc/self/exedir link

[Mike Hearn]

> IMO the program must be aware of the get-my-exedir feature, just configuring
> --prefix=/proc/... is aiming for your feet.

I disagree, though /proc/self/exedir may not be the right answer. The 
problem with the original proposal is there's no concept of a group 
leader to which files are resolved relative to so there is this problem 
with child processes.

I sent a mail outlining a scheme that used file descriptor passing to 
achieve the same effect but with the needed "inheritance" of the path, 
but, vger seems to have munched it! At least I don't see it on the gmane 
archives. But the scheme is simple enough:

  * get_prefix() reads /proc/self/exe and turns it into the correct
    directory

  * dup2(open(get_my_exedir()), 999)

  * ./configure --prefix=/proc/self/fd/999

Obviously that code leaks but you get the idea. Paths can now be 
resolved relative to the magic fd number (whatever numbe is used up to 
the userspace app). The fd is inherited on exec, so sub-programs that 
are passed a path relative to it still work.

It doesn't need kernel support which is nice.

It also restricts the problem to passing paths to other processes that 
are not subprocesses (eg via rpc). But as each process can have its own 
namespace this will always be an issue that needs careful treatment, and 
the pain of adjusting software to realpath() it is much lower than 
modifying every path in every piece of software. That approach was 
already tried and sucks.

thanks -mike

Re: [PATCH] Add a /proc/self/exedir link

[Bodo Eggert]

On Thu, 6 Apr 2006, Mike Hearn wrote:

> > IMO the program must be aware of the get-my-exedir feature, just configuring
> > --prefix=/proc/... is aiming for your feet.
> 
> I disagree, though /proc/self/exedir may not be the right answer. The 
> problem with the original proposal is there's no concept of a group 
> leader to which files are resolved relative to so there is this problem 
> with child processes.

The problem ist the word 'the'. If parent and child are using 'the foo',
they will clash.

> I sent a mail outlining a scheme that used file descriptor passing to 
> achieve the same effect but with the needed "inheritance" of the path, 
> but, vger seems to have munched it! At least I don't see it on the gmane 
> archives. But the scheme is simple enough:
> 
>   * get_prefix() reads /proc/self/exe and turns it into the correct
>     directory
> 
>   * dup2(open(get_my_exedir()), 999)
>
>   * ./configure --prefix=/proc/self/fd/999

bin/foo calls bin/bar refering to /proc/self/fd/999
bin_2/bar does dup2(open(get_my_exedir()), 999)  ***FUBAR***

possible solution:

don't dup2, and only close fds you opened yourself.

Disadvantage: Leaky (too), may break scripts.

.oO(Can you chroot a single filedescriptor or somehow make 
    /proc/self/fd/$n/.. be unavailable?)

> It also restricts the problem to passing paths to other processes that 
> are not subprocesses (eg via rpc). But as each process can have its own 
> namespace this will always be an issue that needs careful treatment, and 
> the pain of adjusting software to realpath() it is much lower than 
> modifying every path in every piece of software. That approach was 
> already tried and sucks.

There may be no "real path" corresponding to /proc/self/fd/4711.

IMO it's still best to just symlink the program directory to the correct 
place and make the programs search in e.g. ~/opt/ and /opt/.
-- 
Fun things to slip into your budget
An abacus

Re: [PATCH] Add a /proc/self/exedir link

[Mike Hearn]

> bin/foo calls bin/bar refering to /proc/self/fd/999
> bin_2/bar does dup2(open(get_my_exedir()), 999)  ***FUBAR***

So don't do that. Treat it as the same case as sending a file path via 
RPC: make sure it's resolved relative to the namespace the program is in 
and not anything under /proc/self.

In practice most desktop apps use "prefix paths" to locate their own 
data files. They don't usually send those file paths to other processes, 
not even in the case of things like GIMP plugins.

So whilst I agree you have identified a place where it breaks, I don't 
think it invalidates the scheme.

> There may be no "real path" corresponding to /proc/self/fd/4711.

Only in a pathological case like running a program that you then rm -rf 
the prefix of, in which case, you lose whatever happens.

> IMO it's still best to just symlink the program directory to the correct 
> place and make the programs search in e.g. ~/opt/ and /opt/.

That also suffers from namespace conflicts ;)

thanks -mike

Re: [PATCH] Add a /proc/self/exedir link

[Eric W. Biederman]

Mike Hearn <mike@plan99.net> writes:

> In practice most desktop apps use "prefix paths" to locate their own data
> files. They don't usually send those file paths to other processes, not even in
> the case of things like GIMP plugins.

Programs that ssh to another machine and run commands are likely
to send paths.

>> IMO it's still best to just symlink the program directory to the correct place
>> and make the programs search in e.g. ~/opt/ and /opt/.
>
> That also suffers from namespace conflicts ;)


I looked at your original proposal some more and it fails
miserably for shell scripts.  Basically they all get / as
their prefix, no matter where in the filesystem you put them.

Also there is a very serious problem with suid exectuables.
If a non privileged user has write access to the same filesystem
the exectuables live on they can create a hard link to those
files and change the prefix.  Quite possibly getting the suid
executables to trust a new set of exectuables.

So this scheme appears to have many if not all of same security issues
as private namespaces.

Given that mostly it will be junior programmers packaging applications
behind the backs of the authors of the code that will implement this
scheme we could introduce all kinds of problems that no one will
notice for quite a while.

Eric

Fwd: [PATCH] Add a /proc/self/exedir link

[Joshua Hudson]

> Also there is a very serious problem with suid exectuables.
> If a non privileged user has write access to the same filesystem
> the exectuables live on they can create a hard link to those
> files and change the prefix.  Quite possibly getting the suid
> executables to trust a new set of exectuables.

Excellent point. This proposal needs to die, but there needs to be some way
to solve this problem.

Re: Fwd: [PATCH] Add a /proc/self/exedir link

[John Stoffel]

>>>>> "Joshua" == Joshua Hudson <joshudson@gmail.com> writes:

Joshua> Excellent point. This proposal needs to die, but there needs
Joshua> to be some way to solve this problem.

Why don't you try to explain the problem in more depth, but without
assuming a solution at all.  Just talk about what you're trying to
fix.  

As a SysAdmin by trade, if the program is written sanely, it's not
hard to make it relocateable and runable from anywhere.  It's when the
program *knows* or the libraries is uses *know* that stuff is in
certain locations that things break.  

I'm really writing from memory here, since I first saw your proposal
and looked it over and went "why bother?" but didn't have the time to
check it out in detail.  

John

Re: [PATCH] Add a /proc/self/exedir link

[Mike Hearn]

Eric W. Biederman wrote:
>> In practice most desktop apps use "prefix paths" to locate their own data
>> files. They don't usually send those file paths to other processes, not even in
>> the case of things like GIMP plugins.
> 
> Programs that ssh to another machine and run commands are likely
> to send paths.

I'm confused again, sorry, these paths would be on the remote machine in 
such a case surely?

> I looked at your original proposal some more and it fails
> miserably for shell scripts.  Basically they all get / as
> their prefix, no matter where in the filesystem you put them.

There is no good way for a shell script to find out where it is, that's 
always been true on Linux and fixing it wasn't a goal of the patch as it 
can be easily done in userspace using a little stub program.

It'd definitely be nice to fix it though.

> Also there is a very serious problem with suid exectuables.
> If a non privileged user has write access to the same filesystem
> the exectuables live on they can create a hard link to those
> files and change the prefix.  Quite possibly getting the suid
> executables to trust a new set of exectuables.

Yes. I don't think that can be fixed in a general way. Again I guess the 
solution would be "don't do that". Maybe the patch could be adapted so 
/proc/self/exedir is not available for suid root programs, to stop 
people making that mistake. Ditto for the fd passing scheme.

> Given that mostly it will be junior programmers packaging applications
> behind the backs of the authors of the code that will implement this
> scheme we could introduce all kinds of problems that no one will
> notice for quite a while.

I guess you are referring to autopackages - whilst simplifying 
relocatability will certainly help junior programmers build such things, 
they're designed to be built or maintained by the original authors of 
the programs themselves (unlike other package formats). Because anybody 
can build them on their own systems, they can be treated like source 
tarballs and maintained as a team.

Allowing packages to be correctly built taking into account the 
subtleties of the software was one of the motivations behind developing 
autopackage ...

thanks -mike