Your message dated Fri, 11 Aug 2017 12:44:51 -0700 with message-id <87o9rlx51o....@iris.silentflame.com> and subject line Closing inactive Policy bugs has caused the Debian Bug report #276160, regarding Path variables in init.d scripts to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 276160: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276160 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: debian-policy Version: 220.127.116.11 Severity: normal [ It has been a week without a comment, I am resending my message as a bug on debian-policy. ] Hi, [ This topic has been discussed before. However, I think it hasn't come to a clear decision. ] Problem is: what should init scripts (scripts in /etc/init.d) assume of their environment, and/or what behavior should they have in environments which aren't sane. In particular, what should they do when the PATH doesn't contain binaries they invoke. This question arises from #262224, and you'll find a starting point for this discussion in the bug report logs. A good lecture is quoted, it is a previous discussion of this problem in april 1999: <http://lists.debian.org/debian-policy/1999/04/threads.html#00143> (The original problem was posted in debian-devel: <http://lists.debian.org/debian-devel/1999/04/thrd2.html#00812>.) I also quote the current Debian Policy in the bug report, but I might have forgotten some sections, please correct me: "Now looking at the Debian Policy, section 9.3 isn't really informative about what to do with the PATH or other environment in /etc/init.d/* scripts. 9.9 tells us programs should not depend on environment variables to function properly, and we should use reasonable defaults. However, in 6.1, which doesn't directly relate to /etc/init.d/* scripts, but talks about shell scripts in general, we read: Programs called from maintainer scripts should not normally have a path prepended to them. Before installation is started, the package management system checks to see if the programs ldconfig, start-stop-daemon, install-info, and update-rc.d can be found via the PATH environment variable. Those programs, and any other program that one would expect to be on the PATH, should thus be invoked without an absolute pathname. Maintainer scripts should also not reset the PATH, though they might choose to modify it by prepending or appending package-specific directories. These considerations really apply to all shell scripts." Below I am numbering the points taken, and assigning letters to the proposed actions, so you can react on a number instead of repeating it's text. Actions that could be taken A) Augment the policy to require a sane environment when calling an init script. B) Augment the PATH in init scripts to be sure it contains at least the required directories, for example: ``PATH="$PATH:/sbin"''. C) Set the PATH unconditionally, to make sure it contains the required directories, for example: ``PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"'' D) Use full pathname of binaries when invoking them from an init script. Interesting points made during the various discussions 1) There is no policy right now, all init scripts behave differently. 2) You can use a wrapper to setup a sane environment if your init script assumes a sane environment. 3) 6.1: "Programs called from maintainer scripts should not normally have a path prepended to them." (Of course, this is different from init scripts, but it still suggests a nice behavior.) dpkg checks for a sane PATH prior to calling maintainer scripts, and hence init scripts called from maintainer scripts can assume a sane environment. 4) init sets a sane PATH at startup, see init(8), and all programs inherit from init. 5) Other variables than PATH are affected, for example TZ or IFS. 6) If every script stores its PATH settings, it's hard to update a global system PATH. I would personnally add that: - invoke-rc.d is a key script that doesn't touch the PATH right now, but could be used to setup a sane environment if we required one ; - /etc/init.d/skeleton should expose the target behavior we seek, right now it hardcodes a PATH setting. Regards, -- Loïc Minier <l...@dooz.org>
--- End Message ---
--- Begin Message ---control: user debian-pol...@packages.debian.org control: usertag -1 +obsolete control: tag -1 +wontfix Russ Allbery and I did a round of in-person bug triage at DebConf17 and we are closing this bug as inactive. The reasons for closing fall into the following categories, from most frequent to least frequent: - issue is appropriate for Policy, there is a consensus on how to fix the problem, but preparing the patch is very time-consuming and no-one has volunteered to do it, and we do not judge the issue to be important enough to keep an open bug around; - issue is appropriate for Policy but there does not yet exist a consensus on what should change, and no recent discussion. A fresh discussion might allow us to reach consensus, and the messages in the old bug are unlikely to help very much; or - issue is not appropriate for Policy. If you feel this bug is still relevant and want to restart the discussion, you can re-open the bug. However, please consider instead opening a new bug with a message that summarises and condenses the previous discussion, updates the report for the current state of Debian, and makes clear exactly what you think should change. A lot of these old bugs have long side tangents and numerous messages, and that old discussion is not necessarily helpful for figuring out what Debian Policy should say today. -- Sean Whitton
Description: PGP signature
--- End Message ---