package/dropbear: fix when readlink is busybox'

Busybox' "readlink -f" does not canonicalise paths when the target is
missing, while coreutils do.

Fix that by:
  - making an absolute symlink
  - dropping "-f" when calling readlink

Fixes #8276.

Reported-by: Jason Tang <tang@jtang.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Tested-by: Jason Tang <tang@jtang.org>
---
 package/dropbear/S50dropbear      | 2 +-
 package/dropbear/dropbear.mk      | 2 +-
 package/dropbear/dropbear.service | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Busybox' "readlink -f" does not canonicalise paths when the target is
 > missing, while coreutils do.

 > Fix that by:
 >   - making an absolute symlink
 >   - dropping "-f" when calling readlink

 > Fixes #8276.

Committed, thanks.

 > --- a/package/dropbear/S50dropbear
 > +++ b/package/dropbear/S50dropbear
 > @@ -18,7 +18,7 @@ start() {
 >  	#   - the filesystem is RW (i.e. we can rm the symlink),
 >  	#     replace the symlink with an actual directory
 >  	if [ -L /etc/dropbear \
 > -	     -a "$(readlink -f /etc/dropbear)" = "/var/run/dropbear" ]
 > +	     -a "$(readlink /etc/dropbear)" = "/var/run/dropbear" ]
 >  	then
 >  		if rm -f /etc/dropbear; then
 >  			mkdir -p /etc/dropbear

Looking at the recent changes to S50dropbear, isn't it quite noisy with
a RO rootfs? I would imagine those rm and mkdir calls complain with
RO. Perhaps we should add 2>/dev/null to them?

Peter, All,

On 2015-08-24 17:09 +0200, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> 
>  > Busybox' "readlink -f" does not canonicalise paths when the target is
>  > missing, while coreutils do.
> 
>  > Fix that by:
>  >   - making an absolute symlink
>  >   - dropping "-f" when calling readlink
> 
>  > Fixes #8276.
> 
> Committed, thanks.
> 
>  > --- a/package/dropbear/S50dropbear
>  > +++ b/package/dropbear/S50dropbear
>  > @@ -18,7 +18,7 @@ start() {
>  >  	#   - the filesystem is RW (i.e. we can rm the symlink),
>  >  	#     replace the symlink with an actual directory
>  >  	if [ -L /etc/dropbear \
>  > -	     -a "$(readlink -f /etc/dropbear)" = "/var/run/dropbear" ]
>  > +	     -a "$(readlink /etc/dropbear)" = "/var/run/dropbear" ]
>  >  	then
>  >  		if rm -f /etc/dropbear; then
>  >  			mkdir -p /etc/dropbear
> 
> Looking at the recent changes to S50dropbear, isn't it quite noisy with
> a RO rootfs? I would imagine those rm and mkdir calls complain with
> RO. Perhaps we should add 2>/dev/null to them?

Well, on a RO filesystem, we'd create /var/run/dropbear on each boot,
and thus regenerate keys on each boot. This means keys from such a
device can not really be trusted.

So I'd prefer we get the error messages, as a clue to the user that
something is wrong. Maybe we could have had an explicit message, yes.

Regards,
Yann E. MORIN.

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

>> Looking at the recent changes to S50dropbear, isn't it quite noisy with
 >> a RO rootfs? I would imagine those rm and mkdir calls complain with
 >> RO. Perhaps we should add 2>/dev/null to them?

 > Well, on a RO filesystem, we'd create /var/run/dropbear on each boot,
 > and thus regenerate keys on each boot. This means keys from such a
 > device can not really be trusted.

Well, with a RO filesystem you only have the option to either generate
at each boot or bake in a hardcoded host key in the rootfs. Neither is
really great for security.

 > So I'd prefer we get the error messages, as a clue to the user that
 > something is wrong. Maybe we could have had an explicit message, yes.

Those fairly obscure messages are imho not really helpful - But on the
other hand I'm not sure a dedicated message is really warranted.

Peter, All,

On 2015-08-24 17:38 +0200, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> 
> Hi,
> 
> >> Looking at the recent changes to S50dropbear, isn't it quite noisy with
>  >> a RO rootfs? I would imagine those rm and mkdir calls complain with
>  >> RO. Perhaps we should add 2>/dev/null to them?
> 
>  > Well, on a RO filesystem, we'd create /var/run/dropbear on each boot,
>  > and thus regenerate keys on each boot. This means keys from such a
>  > device can not really be trusted.
> 
> Well, with a RO filesystem you only have the option to either generate
> at each boot or bake in a hardcoded host key in the rootfs. Neither is
> really great for security.

Or, as some are doing (Paul for example), have /etc/dropbear point to a
R/W location (e.g. a persistent FS done at first boot) and have the
symlink overwritten by an overlay to point to that location.

Which is anyway something sane to do in most case of a R/O FS.

>  > So I'd prefer we get the error messages, as a clue to the user that
>  > something is wrong. Maybe we could have had an explicit message, yes.
> 
> Those fairly obscure messages are imho not really helpful - But on the
> other hand I'm not sure a dedicated message is really warranted.

Maybe something along the lines of;

    I have no persistent location to store SSH host keys.
    I will generate new ones on each boot.
    Are you sure that's what you wanted to do?

Regards,
Yann E. MORIN.

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

>> Well, with a RO filesystem you only have the option to either generate
 >> at each boot or bake in a hardcoded host key in the rootfs. Neither is
 >> really great for security.

 > Or, as some are doing (Paul for example), have /etc/dropbear point to a
 > R/W location (e.g. a persistent FS done at first boot) and have the
 > symlink overwritten by an overlay to point to that location.

 > Which is anyway something sane to do in most case of a R/O FS.

Sure, or simply union mount a persistent R/W FS on top of /etc so you
don't need to mess around with symlinks like I usually do.

 >> Those fairly obscure messages are imho not really helpful - But on the
 >> other hand I'm not sure a dedicated message is really warranted.

 > Maybe something along the lines of;

 >     I have no persistent location to store SSH host keys.
 >     I will generate new ones on each boot.
 >     Are you sure that's what you wanted to do?

I don't feel strongly about it. If you think it is needed then that's
fine by me. I think it sounds a bit odd to use the 'I' form, so perhaps
something like this instead:

No persistent location to store SSH host keys. New keys will be
generated at each boot. Are you sure this is what you want to do?

And perhaps the message should contain hints about how to fix this?