* Re: [PATCH] Add a /proc/self/exedir link [not found] ` <5XGOz-1eP-35@gated-at.bofh.it> @ 2006-04-06 11:39 ` Bodo Eggert 2006-04-06 13:21 ` Mike Hearn 0 siblings, 1 reply; 8+ messages in thread From: Bodo Eggert @ 2006-04-06 11:39 UTC (permalink / raw) To: Neil Brown, Mike Hearn, linux-kernel, akpm 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link 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 0 siblings, 1 reply; 8+ messages in thread From: Mike Hearn @ 2006-04-06 13:21 UTC (permalink / raw) To: 7eggert; +Cc: Neil Brown, linux-kernel, akpm > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link 2006-04-06 13:21 ` Mike Hearn @ 2006-04-06 17:02 ` Bodo Eggert 2006-04-06 19:36 ` Mike Hearn 0 siblings, 1 reply; 8+ messages in thread From: Bodo Eggert @ 2006-04-06 17:02 UTC (permalink / raw) To: Mike Hearn; +Cc: 7eggert, Neil Brown, linux-kernel, akpm 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link 2006-04-06 17:02 ` Bodo Eggert @ 2006-04-06 19:36 ` Mike Hearn 2006-04-07 18:40 ` Eric W. Biederman 0 siblings, 1 reply; 8+ messages in thread From: Mike Hearn @ 2006-04-06 19:36 UTC (permalink / raw) To: Bodo Eggert; +Cc: Neil Brown, linux-kernel, akpm > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link 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:22 ` Mike Hearn 0 siblings, 2 replies; 8+ messages in thread From: Eric W. Biederman @ 2006-04-07 18:40 UTC (permalink / raw) To: Mike Hearn; +Cc: Bodo Eggert, Neil Brown, linux-kernel, akpm 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <bda6d13a0604071201o36496a55o2eae6a65153a06c3@mail.gmail.com>]
* Fwd: [PATCH] Add a /proc/self/exedir link [not found] ` <bda6d13a0604071201o36496a55o2eae6a65153a06c3@mail.gmail.com> @ 2006-04-07 19:01 ` Joshua Hudson 2006-04-07 19:17 ` John Stoffel 0 siblings, 1 reply; 8+ messages in thread From: Joshua Hudson @ 2006-04-07 19:01 UTC (permalink / raw) To: linux-kernel > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Fwd: [PATCH] Add a /proc/self/exedir link 2006-04-07 19:01 ` Fwd: " Joshua Hudson @ 2006-04-07 19:17 ` John Stoffel 0 siblings, 0 replies; 8+ messages in thread From: John Stoffel @ 2006-04-07 19:17 UTC (permalink / raw) To: Joshua Hudson; +Cc: linux-kernel >>>>> "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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Add a /proc/self/exedir link 2006-04-07 18:40 ` Eric W. Biederman [not found] ` <bda6d13a0604071201o36496a55o2eae6a65153a06c3@mail.gmail.com> @ 2006-04-07 19:22 ` Mike Hearn 1 sibling, 0 replies; 8+ messages in thread From: Mike Hearn @ 2006-04-07 19:22 UTC (permalink / raw) To: Eric W. Biederman; +Cc: Bodo Eggert, Neil Brown, linux-kernel, akpm 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-04-07 19:20 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [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 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
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).