Bug#593940: bind9utils: dnssec-{keygen,signzone} should not be in /usr/sbin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#593940: bind9utils: dnssec-{keygen,signzone} should not be in /usr/sbin

Bernhard Schmidt-5
Control: tags -1 + wontfix

On Sun, Aug 22, 2010 at 03:41:49PM +0200, Philipp Kern wrote:

Hi,

> Package: bind9utils
> Version: 1:9.7.1.dfsg.P2-2
> Severity: normal
>
> Why are dnssec-{keygen,signzone} in /usr/sbin?  They are perfectly usable
> from normal user accounts and zone signing actions are not exactly carried
> through by "system binaries" as specified by the FHS.

This is where upstream (and every other distribution) puts these files.
Changing this now would break compatibity with everyone else and
existing scripts referencing the full path name.

Nothing prevents you from calling these programs with the full path (or
changing PATH in your script).

Bernhard

Reply | Threaded
Open this post in threaded view
|

Bug#593940: [Pkg-dns-devel] Bug#593940: bind9utils: dnssec-{keygen, signzone} should not be in /usr/sbin

Daniel Kahn Gillmor-3
Hi all--

On Wed 2017-12-13 16:00:26 +0100, Bernhard Schmidt wrote:
> Control: tags -1 + wontfix

I don't think this is a good resolution for #593940, and i hope we can
revert it.

> On Sun, Aug 22, 2010 at 03:41:49PM +0200, Philipp Kern wrote:
>
>> Package: bind9utils
>> Version: 1:9.7.1.dfsg.P2-2
>> Severity: normal
>>
>> Why are dnssec-{keygen,signzone} in /usr/sbin?  They are perfectly usable
>> from normal user accounts and zone signing actions are not exactly carried
>> through by "system binaries" as specified by the FHS.
>
> This is where upstream (and every other distribution) puts these
> files.
By this argument, we would never fix any upstream bugs at all :)  Debian
has the opportunity to lead the way here.

> Changing this now would break compatibity with everyone else and
> existing scripts referencing the full path name.

Debian policy §6.1 (about maintainer scripts) says:

    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, and update-rc.d can be found via the PATH
    environment variable. Those programs, and any other program that one
    would expect to be in 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.

Note the last sentence ;)

Yes, people do put the full path in their scripts, which makes them
brittle and unfortunate.  Why do people put the full path in their
scripts?  Often it's because the tools they want to use aren't shipped
already in the $PATH.  For example, the useful tools in bind9utils.

So actually fixing this bug would lead to less brittle systems in the
future, which is a good thing.

> Nothing prevents you from calling these programs with the full path (or
> changing PATH in your script).

If we want to continue supporting things that have embedded the full
path, we can ship symlinks in /usr/sbin/ that point back to /usr/bin.

If we shipped these backward-compatibility symlinks, would that be
acceptable to address your concerns?

           --dkg

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#593940: [Pkg-dns-devel] Bug#593940: Bug#593940: bind9utils: dnssec-{keygen, signzone} should not be in /usr/sbin

Ondřej Surý
I think that best course of action would be to wait till January and
fill an upstream issue in an upstream gitlab for BIND ;)

I think this is reasonable, but what about we change this in an upstream
first and then backport the change?

O.
--
Ondřej Surý <[hidden email]>

On Wed, Dec 13, 2017, at 20:18, Daniel Kahn Gillmor wrote:

> Hi all--
>
> On Wed 2017-12-13 16:00:26 +0100, Bernhard Schmidt wrote:
> > Control: tags -1 + wontfix
>
> I don't think this is a good resolution for #593940, and i hope we can
> revert it.
>
> > On Sun, Aug 22, 2010 at 03:41:49PM +0200, Philipp Kern wrote:
> >
> >> Package: bind9utils
> >> Version: 1:9.7.1.dfsg.P2-2
> >> Severity: normal
> >>
> >> Why are dnssec-{keygen,signzone} in /usr/sbin?  They are perfectly usable
> >> from normal user accounts and zone signing actions are not exactly carried
> >> through by "system binaries" as specified by the FHS.
> >
> > This is where upstream (and every other distribution) puts these
> > files.
>
> By this argument, we would never fix any upstream bugs at all :)  Debian
> has the opportunity to lead the way here.
>
> > Changing this now would break compatibity with everyone else and
> > existing scripts referencing the full path name.
>
> Debian policy §6.1 (about maintainer scripts) says:
>
>     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, and update-rc.d can be found via the PATH
>     environment variable. Those programs, and any other program that one
>     would expect to be in 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.
>
> Note the last sentence ;)
>
> Yes, people do put the full path in their scripts, which makes them
> brittle and unfortunate.  Why do people put the full path in their
> scripts?  Often it's because the tools they want to use aren't shipped
> already in the $PATH.  For example, the useful tools in bind9utils.
>
> So actually fixing this bug would lead to less brittle systems in the
> future, which is a good thing.
>
> > Nothing prevents you from calling these programs with the full path (or
> > changing PATH in your script).
>
> If we want to continue supporting things that have embedded the full
> path, we can ship symlinks in /usr/sbin/ that point back to /usr/bin.
>
> If we shipped these backward-compatibility symlinks, would that be
> acceptable to address your concerns?
>
>            --dkg
> _______________________________________________
> pkg-dns-devel mailing list
> [hidden email]
> https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

Reply | Threaded
Open this post in threaded view
|

Bug#593940: [Pkg-dns-devel] Bug#593940: Bug#593940: Bug#593940: bind9utils: dnssec-{keygen, signzone} should not be in /usr/sbin

Bernhard Schmidt-5
On 14.12.2017 09:34, Ondřej Surý wrote:

Hi everyone,

> I think that best course of action would be to wait till January and
> fill an upstream issue in an upstream gitlab for BIND ;)
>
> I think this is reasonable, but what about we change this in an upstream
> first and then backport the change?

I agree. Even with compatibility symlinks, I fear people will be using
/usr/bin/dnssec-* directly, breaking compatibility with other
distributions and upstream. Too much pain for the gain, if it needs to
be carried permanently.

However, if upstream is sympathetic to this and will eventually arrive
there, I have absolutely no objection to backport this. Or if anyone
else in the team wants to push this through.

Bernhard

Reply | Threaded
Open this post in threaded view
|

Bug#593940: [Pkg-dns-devel] Bug#593940: Bug#593940: bind9utils: dnssec-{keygen, signzone} should not be in /usr/sbin

Daniel Kahn Gillmor-3
In reply to this post by Ondřej Surý
Control: forwarded 593940 https://bugs.isc.org/Public/Bug/Display.html?id=46949

On Thu 2017-12-14 09:34:56 +0100, Ondřej Surý wrote:
> I think that best course of action would be to wait till January and
> fill an upstream issue in an upstream gitlab for BIND ;)

i don't see any gitlab for BIND, but i do see the RT instance over at
https://bugs.isc.org/Public/Dist/Display.html?Name=bind9-public.

given that it's january, i've gone ahead and filed a bug report
upstream (it doesn't seem to be visible to the public yet):

   https://bugs.isc.org/Public/Bug/Display.html?id=46949

   --dkg

Reply | Threaded
Open this post in threaded view
|

Bug#593940: [Pkg-dns-devel] Bug#593940: Bug#593940: bind9utils: dnssec-{keygen, signzone} should not be in /usr/sbin

Bernhard Schmidt
On Wed, Jan 03, 2018 at 02:35:18PM -0500, Daniel Kahn Gillmor wrote:

Hi,

> On Thu 2017-12-14 09:34:56 +0100, Ondřej Surý wrote:
> > I think that best course of action would be to wait till January and
> > fill an upstream issue in an upstream gitlab for BIND ;)
>
> i don't see any gitlab for BIND, but i do see the RT instance over at
> https://bugs.isc.org/Public/Dist/Display.html?Name=bind9-public.
>
> given that it's january, i've gone ahead and filed a bug report
> upstream (it doesn't seem to be visible to the public yet):
>
>    https://bugs.isc.org/Public/Bug/Display.html?id=46949

It's still not public, and I think the migration to the Gitlab tracker
is a manual process.

Would you mind filing it again at
https://gitlab.isc.org/isc-projects/bind9/issues ?

Thanks,
Bernhard