From: Bodo Eggert <7eggert@gmx.de>
To: Mike Hearn <mike@plan99.net>
Cc: 7eggert@gmx.de, Neil Brown <neilb@suse.de>,
linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] Add a /proc/self/exedir link
Date: Thu, 6 Apr 2006 19:02:44 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.58.0604061841150.1941@be1.lrz> (raw)
In-Reply-To: <443515E1.1000600@plan99.net>
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
next prev parent reply other threads:[~2006-04-06 17:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5XGlt-GY-23@gated-at.bofh.it>
[not found] ` <5XGOz-1eP-35@gated-at.bofh.it>
2006-04-06 11:39 ` [PATCH] Add a /proc/self/exedir link Bodo Eggert
2006-04-06 13:21 ` Mike Hearn
2006-04-06 17:02 ` Bodo Eggert [this message]
2006-04-06 19:36 ` Mike Hearn
2006-04-07 18:40 ` Eric W. Biederman
[not found] ` <bda6d13a0604071201o36496a55o2eae6a65153a06c3@mail.gmail.com>
2006-04-07 19:01 ` Fwd: " Joshua Hudson
2006-04-07 19:17 ` John Stoffel
2006-04-07 19:22 ` Mike Hearn
2006-04-03 23:01 Mike Hearn
2006-04-03 23:26 ` Joshua Hudson
2006-04-03 23:30 ` Neil Brown
2006-04-04 15:54 ` Jan Engelhardt
2006-04-04 21:24 ` Nix
2006-04-05 20:39 ` Eric W. Biederman
2006-04-05 21:52 ` Mike Hearn
2006-04-06 23:33 ` Tony Luck
2006-04-07 7:52 ` Neil Brown
2006-04-07 9:15 ` Andreas Schwab
2006-04-07 19:10 ` Eric W. Biederman
2006-04-08 8:26 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.58.0604061841150.1941@be1.lrz \
--to=7eggert@gmx.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mike@plan99.net \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).