looks like when i emerge openvpn, it records the full path to networking utils: checking for ifconfig... /bin/ifconfig checking for ip... /sbin/ip checking for route... /bin/route checking for netstat... /bin/netstat it then uses those at runtime: Mar 06 18:00:10 [openvpn] /bin/ifconfig tun0 10.8.8.2 pointopoint 10.8.8.3 mtu 1500 Mar 06 18:00:10 [openvpn] /bin/route add -net 10.8.8.0 netmask 255.255.255.0 gw 10.8.8.3 that's obviously no good if the tools change location, which they are. consider a previous run that was failing: Mar 06 17:52:35 [openvpn] /sbin/ifconfig tun0 10.8.8.2 pointopoint 10.8.8.3 mtu 1500 Mar 06 17:52:35 [openvpn] Linux ifconfig failed: could not execute external program Mar 06 17:52:35 [openvpn] Exiting openvpn needs to discover these things at runtime via $PATH
openvpn records 4 paths in its configure: IFCONFIG_PATH, IPROUTE_PATH, ROUTE_PATH, NETSTAT_PATH. It provides a runtime parameter '--iproute' to specify the path to "ip", overriding the hardwired IPROUTE_PATH, if openvpn is built with 'iproute2' USE flag. And actually openvpn[iproute2] does not use the other 3 hardwired paths at all. So for openvpn[iproute2] it's possible to completely solve the problem by letting openvpn's initscript discover the path to "ip" dynamically, and pass it to openvpn with --iproute, just a few extra lines in /etc/init.d/openvpn. (Note, though, openvpn[-iproute2] probably exits when it catches '--iproute' as an "unrecognized option".) For openvpn[-iproute2] things look tricky and a patch is definitely required. Another issue is openvpn always uses hardwired paths on non-Linux systems like Gentoo/FreeBSD.
With net-tools-1.60_p20120127084908 (which moves ifconfig location), this also means openvpn recompilation is needed after update at the moment
Reason: security product cannot search tools in path. Recommendation: USE="iproute2" And then you have a configuration option of iproute to specify which tool to use.
that's crap. if you can run openvpn as your user, you can sure as well manipulate its memory at runtime and tell it to do whatever you want. if you're launching it as root, you certainly can control the initial env.
*** Bug 410781 has been marked as a duplicate of this bug. ***
*** Bug 431604 has been marked as a duplicate of this bug. ***
*** Bug 434482 has been marked as a duplicate of this bug. ***
*** Bug 444768 has been marked as a duplicate of this bug. ***
Perhaps bug 444444 is also a duplicate?
*** Bug 444444 has been marked as a duplicate of this bug. ***
Tell me that, if it was confirmed more then half year ago, why it is not fixed yet ?
So far, upstream has not wanted to do anything about it.
my reading of the code indicates they use execve() because they want to pass down the argv/envp arrays. that last part is important -- while there is an execvpe(), it is not portable. then again, openvpn is already enabling AC_GNU_SOURCE when it's available, so that isn't a big deal. otherwise, the logic would have to use execvp and manually sync the environ after the fork() ...
Created attachment 330600 [details, diff] use execvpe if available i've only done a compile-time test. don't have local access to my main system atm to do a runtime test.
In the mean time, rebuilding openvpn would work for users who run into this. I just talked to upstream, and they're working on solving this for 2.4 using netlink sockets.
*** Bug 444842 has been marked as a duplicate of this bug. ***
Why wouldn't you push openvpn-r1 for now, so users would be forced to rebuild it? I hit that bug too and it cased me unnecessary downtime.
Yes a revbump with adjusted dependencies it a good workaround at the moment
(In reply to comment #3) > Reason: security product cannot search tools in path. > > Recommendation: > USE="iproute2" > > And then you have a configuration option of iproute to specify which tool to > use. Sorry for off-topic, but where I can find documentation/more info about this? I mean, what's the difference for end-user between using net-tools or iproute2 internally by openvpn? And what is iproute options you're talking about?
(In reply to comment #19) > (In reply to comment #3) > > Reason: security product cannot search tools in path. > > > > Recommendation: > > USE="iproute2" > > > > And then you have a configuration option of iproute to specify which tool to > > use. > > Sorry for off-topic, but where I can find documentation/more info about this? > I mean, what's the difference for end-user between using net-tools or > iproute2 internally by openvpn? And what is iproute options you're talking > about? The difference is in whether openvpn uses "ip" instead of "route" from net-tools to add a route. Some of us prefer to use iproute2 exclusively. See http://inai.de/2008/02/19 for the reasons. This bug concerns the issue whereby openvpn fails because the the location of the ip binary has changed as of a recent iproute2 package update.
(In reply to comment #14) > Created attachment 330600 [details, diff] [details, diff] > use execvpe if available > > i've only done a compile-time test. don't have local access to my main > system atm to do a runtime test. I just tested this based on the upgrade scenario that was my undoing. I built openvpn with this patch and, after restarting, it invoked /bin/ip correctly. Then I downgraded iproute2 from 3.6.0 to 3.3.0, which installs to /sbin/ip. I restarted openvpn and it was still able to invoke ip. Excellent.
*** Bug 451320 has been marked as a duplicate of this bug. ***
Was about to add symlinks to get openvpn to work. The patch smoothly solved it - thanks. I'd vote for making an openvpn-2.2.2-r1.ebuild with the patch until upstream reacts.
How about just pass non-paths to ./configure? https://bugs.gentoo.org/show_bug.cgi?id=451320#c0
(In reply to comment #24) have you actually tested that beyond a configure+compile ? i'm guessing not. as the documentation for execve() states, the first argument is *not* searched via $PATH, it's executed directly. thus if you don't give it a full path, it'll implicitly run $PWD/filename. a simple test shows that: $ echo 'main(){execve("true",0,0);}' | gcc -x c -o a.out - $ strace -eexecve ~/a.out execve("./a.out", ["./a.out"], [/* 73 vars */]) = 0 execve("true", [0], [/* 0 vars */]) = -1 ENOENT (No such file or directory) $ cd /bin $ strace -eexecve ~/a.out execve("/home/vapier/a.out", ["/home/vapier/a."...], [/* 74 vars */]) = 0 execve("true", [0], [/* 0 vars */]) = 0
(In reply to comment #25) Eh, right, my bad. Sorry for the noise. Sat Jan 12 02:37:30 2013 ifconfig tun0 172.16.0.4 pointopoint 172.16.0.1 mtu 1500 Sat Jan 12 02:37:30 2013 Linux ifconfig failed: could not execute external program
*** Bug 454258 has been marked as a duplicate of this bug. ***
All of the net-tools package, including ifconfig, is a pile of unmaintained defunct crap (just look at the recent commit history upstream - it's all small stop-gap patches to prevent it from breaking for systems that still need it.) If it's causing problems, let's just require iproute2 as a dep and be done with it. ifconfig uses the old 2.2 and earlier kernel ioctl interface and upstream (the net-tools maintainers) have no interest in changing that. The `ip` utility and all others provided by iproute2, are the "new standard" and use the kernel interface introduced in 2.4. Unless someone actually is running a 2.2 kernel, such a dep won't cause an undue burden. I'm very much in favor of requiring iproute2 verses applying needless patches to upstream code for the sole purpose of playing nice with effectively deprecated tools. At the very least, don't patch upstream code when --enable-iproute2 is passed to ./configure since it's not required.
(In reply to comment #28) err, net-tools is maintained just fine. we aren't generally adding extended interfaces when iproute2 already supports it, but for most people, net-tools gets the job done fine. but your bile is misdirected. requiring iproute won't affect this bug at all. openvpn hardcodes absolute paths to net-tools and iproute2 equally.
(In reply to comment #29) Replying to the important bit first, > but your bile is misdirected. requiring iproute won't affect this bug at > all. openvpn hardcodes absolute paths to net-tools and iproute2 equally. Not quite since iproute2 didn't go through a binary re-location. You're right that it would suffer the same problem if it was installed to $PREFIX/usr/sbin/ instead of $PREFIX/sbin/ though. Since that hasn't happened, forcing iproute2 as a USE flag would indeed fix the issue people have reported here. > err, net-tools is maintained just fine. we aren't generally adding extended > interfaces when iproute2 already supports it, but for most people, net-tools > gets the job done fine. Interesting. Upstream recently "deprecated" (their words, not mine) netstat. So much for "maintained just fine" it would seem. We're past the 2.4 kernel stage now, and it's time to use tools that reflect that. The replacement for netstat you ask? Upstream (net-tools) maintainers tell you to use iproute2 (ip and ss.) Go figure. Citation: http://net-tools.git.sourceforge.net/git/gitweb.cgi?p=net-tools/net-tools;a=commit;h=77d0c1b2a55c1af31cce4df68da7bf93c8155111
(In reply to comment #30) yes, it did. i know it did because i made the commit. <iproute-3.5.1: /sbin/ip >=iproute-3.5.1: /bin/ip i'm aware of net-tools upstream status. if you read the git history, you'll see i've personally made plenty of commits to it.
Created attachment 345840 [details, diff] Dynamic iproute support and detection Sorry, you're quite right about the path change to iproute2's ip binary as well. So, moving forward, Comment #3 shows that --iproute exists as a runtime solution to this problem. I've attached a patch (dynamic-iproute-detection.patch) that uses iproute2 as a dep and dynamically picks up the location to pass to the --iproute argument to openvpn. This feature is only enabled under Linux, and controllable through the /etc/conf.d/openvpn config file. This way, changes to the path of 'ip' will not break by default as a user would have to explicitly disable the preference of this automatic detection.
(In reply to comment #32) i think the patch i already posted to use execvpe is a lot less invasive
(In reply to comment #33) > (In reply to comment #32) > > i think the patch i already posted to use execvpe is a lot less invasive It certainly is. Did either yourself or Dirkjan propose it upstream? Assuming they're not interested, is there any chance of your patch being incorporated in Gentoo anyway?
(In reply to comment #34) i've only tested+posted it here. i'm not familiar with openvpn upstream, so i haven't bothered posting it. feel free to run with it :).
See comment 15 on what upstream's ideas are.
Gentoo has always been a distribution about choice. The source changes proposed to the upstream openvpn codebase remove an important security feature to prevent overloading the environment's path. While this may not be a concern for some people, the proposed change makes it so for everyone building from the ebuild, including users who care about such security changes. And the proposed benefit? Why are we considering a patch that removes a by-design security feature all so some users don't need to rebuild if the path of the ip or ifconfig binary changes? At the very least, provide an interface for users who do not wish to reduce the security of their system by not strictly controlling the environment, as the code is designed to do. OpenVPN goes out of its way to act as a security product; please don't undermine that goal for the convenience of avoiding a recompile of a single package. The patch I've proposed is less "invasive" in the sense that it does not force users to trade security for minor convenience. In fact, I'd recommend the default be changed to "no" in my patch; then users may decide to make the security tradeoff themselves if this is a big enough concern for their use-case. And if upstream does use netlink sockets for 2.4, this all goes away anyway.
I have to agree with Josh. Arguing that changing the code base is somehow less invasive than altering some configuration files is utterly illogical.
(In reply to comment #37) waving your hands and saying "it's for security!" is crap. openvpn isn't set*id which means the person executing the openvpn programs have full control over the environment, the runtime memory, and just about everything else. hardcoding paths to programs in a futile attempt to "protect" against the $PATH env var being set to malicious locations is entirely pointless and adds 0 security.
*** Bug 466908 has been marked as a duplicate of this bug. ***
bug 444444 was is a dupe of this bug, so it's a loop and won't cross itself off. what's the next step here?
(In reply to Matthew Thode ( prometheanfire ) from comment #41) we're waiting for the openvpn maintainers to merge the patch i posted to use execvpe. or to give the go ahead for someone else to merge it.
Upstream has not seen any compelling arguments why we would want to add that change. ifconfig, route, ip are system parameters and on a normal distribution, they just don't move around "just so", so this would really only for the benefit of gentoo - and you can fix it locally by just re-emerging when (once every 10 years) one of the network binaries moves around
(In reply to Gert Doering from comment #43) the moving of tools in $PATH is happening in all distros (the net-tool changes were merged upstream and not just in Gentoo), so all distros will need to handle this. i meant to get the iproute2 change pushed up too, but i haven't gotten around it. conversely, there's no real compelling arguments why the paths need to be hardcoded at build time.
any update on this?
it's up to djc@, but i can merge this for 2.3.x in the mean time if he doesn't mind. fixing things in 2.4 to use netlink sockets sounds great, but doesn't help us with 2.3 now ...
give it another month or two, and i'll probably just merge it
In reply to #44: on other distributions, such a change (moving of system binaries elsewhere) would normally happen as part of a version upgrade - and part of that upgrade would be "recompile everything that relies on the binaries that have moved". So Gentoo is a bit special here as there are no fixed "releases" and "upgrades" between them - but I still fail to see what's wrong with just bumping the version number of the openvpn ebuild if such a move happens, get it recompiled, issue solved? This is a one-time issue, unless you're not planning to move around ifconfig/route on a more frequent basis in the future (which I strongly hope you're not going to do).
I'd prefer not to take your fix and instead bump the package as needed.
(In reply to Dirkjan Ochtman from comment #49) bump to what ? unless i'm missing something, upstream won't have a sane version for quite a long time (it's been years already).
Yes, but a revbump will rebuild it for everyone with the new paths.
(In reply to SpanKY from comment #50) > (In reply to Dirkjan Ochtman from comment #49) > > bump to what ? unless i'm missing something, upstream won't have a sane > version for quite a long time (it's been years already). Uh, what? Just add a subrevision to the ebuild. Besides that, I'm not sure what you mean by "upstream won't have a sane version for quite a long time" - we just released 2.3.3 two weeks ago, and will release 2.3.4 this week, both of which are "from the stable train". 2.3.2 was released 11 months ago, which I wouldn't call "years already" either. Could you elaborate what is "not sane" about this?
I think by "sane version" I think he means nothing that does netlink sockets, or otherwise not relying on build-time paths. It doesn't seem like Mike and upstream/Gert can reach agreement on what is "sane" related to the build-time paths, but I'd rather not take this execvpe patch.
(In reply to Dirkjan Ochtman from comment #53) > I think by "sane version" I think he means nothing that does netlink > sockets, or otherwise not relying on build-time paths. OK, if that's the definition of "sanity", we will only provide insane releases for quite a while to come - what we have now isn't pretty and smells a bit musty after the decades, but is very well tested on all supported platforms. 2.4 will bring nice stuff, possibly even "sanity", but right now, there's still stuff that is just kaput if you choose the right combination of platform and build flags...
(In reply to Dirkjan Ochtman from comment #51) yes, if we put a blocker on older versions of net-tools/iproute2 and add a revbump, we can continue to bury our heads in the sand and most users won't notice an issue.
This bug has gotten really old, can you please retry with openvpn-2.3.12 and see if the issue still exists?
net-misc/openvpn-2.3.12 suffers from the same issue. After merging it, I moved /bin/ip to /usr/bin/ip and started the daemon. The daemon failed because it was no able to execute /bin/ip: Sep 2 18:37:14 album openvpn[18116]: TUN/TAP device foo0 opened Sep 2 18:37:14 album openvpn[18116]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Sep 2 18:37:14 album openvpn[18116]: /bin/ip link set dev foo0 up mtu 1360 Sep 2 18:37:14 album openvpn[18116]: Linux ip link set failed: could not execute external program Sep 2 18:37:14 album openvpn[18116]: Exiting due to fatal error
(In reply to Petr Pisar from comment #57) > net-misc/openvpn-2.3.12 suffers from the same issue. And it will continue to do so, see my comments #43, #48 and others - OpenVPN upstream does not consider arbitrary moving of system binaries to be something we need or want to support. See said comments for the reasoning behind: in distributions with a regular release schedule, this just does not happen - if system binaries move, it's a distribution upgrade, and all dependent packages get upgraded/recompiled accordingly. Gentoo can work around this (if this should ever be needed again) by bumping the ebuild version on openvpn, so it gets recompiled - but just how often do you plan to move around "ifconfig", "route" or "ip"?
