[Buildroot] Creation of /etc/dropbear

[Buildroot] Creation of /etc/dropbear

[Luca Ceresoli]

Hi,

I have a Buildroot-based project where the target rootfs is read-only,
and there is a writable partition mounted on /mnt/user.

When it is first started, dropbear creates keys in /etc/dropbear. In
order to make this possible, in my board rootfs additions I create
/etc/dropbear as a a symlink to /mnt/user/etc/dropbear, which is an
initially empty directory in the writable partition.

It all works just fine, except when I rebuild a project without doing
'make clean' and dropbear is built (this could happen because its
version was bumped, or because I do make dropbear-rebuild or whatever
else). Here the dropbear install step calls

         mkdir -p $(TARGET_DIR)/etc/dropbear

And fails, because $(TARGET_DIR)/etc/dropbear already exists but is not
a directory: it is a broken symlink.

I'd like to solve this issue in an upstream-friendly way, but I'm not
sure which way is the best. Nothing can be done in a post-build or
post-image script, because the issue is raised way before, when
building the dropbear package.

A simple option would be to remove the directory before creating it,
assuming there's no valuable info in there:

+       rm -fr $(TARGET_DIR)/etc/dropbear
         mkdir -p $(TARGET_DIR)/etc/dropbear

A safer way would be to check if it exists either as a directory or
as a symlink:

+       if [ ! -d $(TARGET_DIR)/etc/dropbear ] && \
+          [ ! -L $(TARGET_DIR)/etc/dropbear ] ; then
                 mkdir -p $(TARGET_DIR)/etc/dropbear
+       fi

Both would work, but what if the same problem happens in other places?
There would be the risk to sprinkling similar ifs here and there in the
Buildroot codebase.

Moreover neither of these solutions looks very clean.

Any better ideas?

Thanks,
-- 
Luca

[Buildroot] Creation of /etc/dropbear

[Thomas De Schampheleire]

Hi Luca,

On Thu, Nov 6, 2014 at 4:19 PM, Luca Ceresoli <luca@lucaceresoli.net> wrote:
> Hi,
>
> I have a Buildroot-based project where the target rootfs is read-only,
> and there is a writable partition mounted on /mnt/user.
>
> When it is first started, dropbear creates keys in /etc/dropbear. In
> order to make this possible, in my board rootfs additions I create
> /etc/dropbear as a a symlink to /mnt/user/etc/dropbear, which is an
> initially empty directory in the writable partition.
>
> It all works just fine, except when I rebuild a project without doing
> 'make clean' and dropbear is built (this could happen because its
> version was bumped, or because I do make dropbear-rebuild or whatever
> else). Here the dropbear install step calls
>
>         mkdir -p $(TARGET_DIR)/etc/dropbear
>
> And fails, because $(TARGET_DIR)/etc/dropbear already exists but is not
> a directory: it is a broken symlink.
>
> I'd like to solve this issue in an upstream-friendly way, but I'm not
> sure which way is the best. Nothing can be done in a post-build or
> post-image script, because the issue is raised way before, when
> building the dropbear package.
>
> A simple option would be to remove the directory before creating it,
> assuming there's no valuable info in there:
>
> +       rm -fr $(TARGET_DIR)/etc/dropbear
>         mkdir -p $(TARGET_DIR)/etc/dropbear
>
> A safer way would be to check if it exists either as a directory or
> as a symlink:
>
> +       if [ ! -d $(TARGET_DIR)/etc/dropbear ] && \
> +          [ ! -L $(TARGET_DIR)/etc/dropbear ] ; then
>                 mkdir -p $(TARGET_DIR)/etc/dropbear
> +       fi
>
> Both would work, but what if the same problem happens in other places?
> There would be the risk to sprinkling similar ifs here and there in the
> Buildroot codebase.

In my case, the rootfs is also not persistent, but mounted read-write.
In this case, I have an init script that restores the keys from
persistent storage into /etc/dropbear and an exit script that saves
the keys to persistent storage. All this after checking that the keys
are valid using dropbearkey.

If you could mount your roofs as read-write, then the same approach
could be taken, or alternatively the symlink could be created from an
init script.

Of course, when mounting the rootfs truly read-only, neither approach works.

Best regards,
Thomas

[Buildroot] Creation of /etc/dropbear

[Gustavo Zacarias]

On 11/06/2014 12:29 PM, Thomas De Schampheleire wrote:

> In my case, the rootfs is also not persistent, but mounted read-write.
> In this case, I have an init script that restores the keys from
> persistent storage into /etc/dropbear and an exit script that saves
> the keys to persistent storage. All this after checking that the keys
> are valid using dropbearkey.
> 
> If you could mount your roofs as read-write, then the same approach
> could be taken, or alternatively the symlink could be created from an
> init script.
> 
> Of course, when mounting the rootfs truly read-only, neither approach works.

Overlayfs /etc, it won't matter if root is RO in that case.
(alternatively aufs or other implementation as well).
Also you could bind-mount /etc/dropbear if it's a directory (which it is
given what the package does) from some other rw directory of your choosing.
Regards.

[Buildroot] Creation of /etc/dropbear

[Luca Ceresoli]

Thomas, Gustavo,

thank you very much for your suggestions.

Gustavo Zacarias wrote:
 > On 11/06/2014 12:29 PM, Thomas De Schampheleire wrote:
>
>> In my case, the rootfs is also not persistent, but mounted read-write.
>> In this case, I have an init script that restores the keys from
>> persistent storage into /etc/dropbear and an exit script that saves
>> the keys to persistent storage. All this after checking that the keys
>> are valid using dropbearkey.
>>
>> If you could mount your roofs as read-write, then the same approach
>> could be taken, or alternatively the symlink could be created from an
>> init script.
>>
>> Of course, when mounting the rootfs truly read-only, neither approach works.

Theoretically the systems in object can be remounted read-only, but I
do not want that. The main issue is that the user can upgrade the entire
rootfs, completely overwriting the old one. Thus, if dropbear stored
the keys in the rootfs, they would be lost during a firmware upgrade and
would be regenerated at the next boot, but they would differ.

This is why I keep all user-modifiable settings in another filesystem,
that is not modificed during software upgrades.

>
> Overlayfs /etc, it won't matter if root is RO in that case.
> (alternatively aufs or other implementation as well).

This would theoretically work, but the kernel in these devices has no 
support for any union fs. I like them to be simple: more features, more
bugs, and I don't really want to add a non-trivial feature when I can
just add one line in dropbear.mk, with zero overhead for the target.

But do not despair because...

> Also you could bind-mount /etc/dropbear if it's a directory (which it is
> given what the package does) from some other rw directory of your choosing.

...this would really work, and it has negligible impact on the target.
Currently I'm using symlinks for this kind of stuff, but bind mounting
leads to the same result, as far as my needs are concerned.
Yes, this would be acceptable.

However I still would like to explore a solution in the build process,
not changing the target. This is not a target problem after all, and the
problem did not exits before [1] was committed in the 2014.08 cycle.

Another solutions in Buildroot that I thought of would be to add

   define DROPBEAR_REMOVE_ETC_DIR
           rm -fr $(TARGET_DIR)/etc/dropbear
   endef

   DROPBEAR_PRE_INSTALL_TARGET_HOOKS += DROPBEAR_REMOVE_ETC_DIR

in some .mk file in boards/<my_company>/ or packages/<my_company>/.
Absolutely dirty, but it does not touch package/dropbear/, thus it is
compatible with BR2_EXTERNAL.

One more solution would be adding a pre-build script, similar to the
post-build script but executed before building any package. This would
be non-trivial to implement, and overkill for solving my little need. I
wonder if a pre-build script might have more use cases that mine, which
might make it an interesting new feature.

[1] 
http://git.buildroot.net/buildroot/commit/package/dropbear?id=fe823b63741ba8eca70a534207d655f5affa927c

Regards,
-- 
Luca