Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 365955 - sys-apps/openrc runscript does not parse symlinks correctly if the target starts with "./"
Summary: sys-apps/openrc runscript does not parse symlinks correctly if the target sta...
Status: RESOLVED DUPLICATE of bug 350910
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: OpenRC Team
: 366819 (view as bug list)
Depends on:
Reported: 2011-05-04 13:19 UTC by vm
Modified: 2011-07-27 15:17 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

0001-fix-handling-of-symbolic-links-in-init.d-directory.patch (0001-fix-handling-of-symbolic-links-in-init.d-directory.patch,1.81 KB, text/plain)
2011-07-22 18:12 UTC, William Hubbs

Note You need to log in before you can comment on or make changes to this bug.
Description vm 2011-05-04 13:19:34 UTC
runscript parses symlinks whose targets start with ./ incorrectly:

root@l:/etc/init.d # rm net.eth0
root@l:/etc/init.d # ln -s ./net.lo net.eth0
root@l:/etc/init.d # /etc/init.d/net.eth0 start
 * WARNING: . is already starting
root@l:/etc/init.d # /etc/init.d/net.eth0 status
/lib/rc/sh/ line 13: .: /etc/init.d/../conf.d/.: is a
 * .: error loading /etc/init.d/../conf.d/.
root@l:/etc/init.d # /etc/init.d/net.eth0 zap
 * Manually resetting . to stopped state
 * rc_service_mark: Is a directory
root@l:/etc/init.d # rm net.eth0
root@l:/etc/init.d # ln -s net.lo net.eth0
root@l:/etc/init.d # /etc/init.d/net.eth0 zap
 * Manually resetting net.eth0 to stopped state
root@l:/etc/init.d # /etc/init.d/net.eth0 start
 * Caching service dependencies ...
 * [ ok ]
 * Bringing up interface eth0
 *   dhcp ...

The problem is that the dirname() call at runscript.c:1136 modifies lnk, so an incorrect name is returned by the basename() call at runscript.c:1140.
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2011-05-12 23:05:46 UTC

*** This bug has been marked as a duplicate of bug 350910 ***
Comment 2 William Hubbs gentoo-dev 2011-05-19 15:04:51 UTC
*** Bug 366819 has been marked as a duplicate of this bug. ***
Comment 3 Christian Ruppert (idl0r) gentoo-dev 2011-06-04 14:56:18 UTC

*** This bug has been marked as a duplicate of bug 350910 ***
Comment 4 William Hubbs gentoo-dev 2011-06-04 17:13:51 UTC
I do not see this as a duplicate of #350910.

Basically, if a symbolic link links to something in the current
directory, we should be able to resolve that, but it doesn't do anything
about the other issue.
Comment 5 Christian Ruppert (idl0r) gentoo-dev 2011-06-04 17:16:54 UTC
That's related to the other bug and to my patch. It should be fixed in git already. Symlink handling in general was/is? broken, both bugs are related to the same part of code.
Comment 6 William Hubbs gentoo-dev 2011-07-22 18:12:20 UTC
Created attachment 280657 [details]


I've thought about this quite a bit and I think the best way to go is to
enforce the requirement from this comment in the openrc source code:

/* We need to work out the real full path to our service.
 * This works fine, provided that we ONLY allow multiplexed services
 * to exist in the same directory as the master link.
 * Also, the master link as to be a real file in the init dir. */

 The attached patch does this. What do you think about going this route?
Comment 7 vm 2011-07-23 20:51:37 UTC
Works for me.
Comment 8 William Hubbs gentoo-dev 2011-07-27 15:17:15 UTC

after further discussion with robbat2 on irc yesterday, I believe that
fixing bug #350910 will fix this as a side effect.

It is technically not a duplicate, but it seems that marking this as a
duplicate and moving all of the work to the other bug will be the
easiest way to track this.

*** This bug has been marked as a duplicate of bug 350910 ***