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

[Mike Hearn <mike@plan99.net>]

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