Patchwork [1/2] system: set root password only for default skeleton

login
register
mail settings
Submitter Yann E. MORIN
Date Jan. 5, 2013, 2:52 p.m.
Message ID <1f2432a8027f1e1c780a45b488be8be03f1b1b93.1357397453.git.yann.morin.1998@free.fr>
Download mbox | patch
Permalink /patch/209679/
State Accepted
Commit b98b191b5cb628ed8dd32236c4b08d025b65941f
Headers show

Comments

Yann E. MORIN - Jan. 5, 2013, 2:52 p.m.
In case one is using a custom skeleton, the root pasword might already be
set in this case, and should not be overriden.

Just ask for (and set) the root password only for the default skeleton.

Reported-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
---
 system/Config.in |   42 +++++++++++++++++++++---------------------
 system/system.mk |    2 ++
 2 files changed, 23 insertions(+), 21 deletions(-)
Steve Calfee - Jan. 7, 2013, 2:46 a.m.
On Sat, Jan 5, 2013 at 6:52 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> In case one is using a custom skeleton, the root pasword might already be
> set in this case, and should not be overriden.
>
> Just ask for (and set) the root password only for the default skeleton.
>
> Reported-by: Gustavo Zacarias <gustavo@zacarias.com.ar>

Hi Yann, all,

This is another change that in my opinion goes against the philosophy
of buildroot. It is another change that tries to make BR a swiss army
knife, (can do anything, nothing well). I would prefer a stiletto or
Bowie Knife - good for one thing, but very good at that.

Why do we need yet another change to enable something easily done with
the post build patch script? An easily built bsp skeleton with an
etc/shadow file handles this beautifully. This kind of creeping
feature requires maintenance, documentation etc. Why?

We need to separate people who build things using buildroot and end
users that use those things. Is it real to think an end user will
build from scratch with buildroot? There are full featured
distributions for most popular platforms that contain this kind of
stuff. For true embedded developers, adding more things like this just
complicate things, does not make it easier.

I guess this is the sort of thing it would be good for the European
Buildrooters to discuss at their next conference.

Regards, Steve
Yann E. MORIN - Jan. 7, 2013, 6:47 p.m.
Steve, All,

On Monday 07 January 2013 Steve Calfee wrote:
> On Sat, Jan 5, 2013 at 6:52 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > In case one is using a custom skeleton, the root pasword might already be
> > set in this case, and should not be overriden.
> >
> > Just ask for (and set) the root password only for the default skeleton.
> >
> > Reported-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> 
> Hi Yann, all,
> 
> This is another change that in my opinion goes against the philosophy
> of buildroot.

IIRC, there have been some complaints on the list by users that just
wondered what was the root password:
    https://bugs.busybox.net/show_bug.cgi?id=5366
    http://lists.busybox.net/pipermail/buildroot/2012-August/057017.html

Having this prompt in the menuconfig makes it clear to the user that
Buildroot does not use a hard-coded secret password.

> Why do we need yet another change to enable something easily done with
> the post build patch script? An easily built bsp skeleton with an
> etc/shadow file handles this beautifully. This kind of creeping
> feature requires maintenance, documentation etc. Why?

Well, that's basically where our view diverges:
  - first, it is not trivial for everybody. It is for me, and I understand
    it is for you. But many people come to buildroot with little previous
    knowledge of Linux in general, and often even less about embdded Linux
    in particular;
  - second, it makes it clear to the user what the root password is (see
    above).

> We need to separate people who build things using buildroot and end
> users that use those things. Is it real to think an end user will
> build from scratch with buildroot?

I am not sure what you mean by:
  - people who build things with Buildroot,
  - end users.

To me there are:
  A) Buildroot developpers, who change Buildroot code,
  B) Buildroot users, who build appliances,
  C) users of appliances built with Buildroot.

Where:
  - {A} ⊂ {B}
  - {A} ∩ {C} ≠ {Ø}
  - {B} ∩ {C} ≠ {Ø}

IMHO, Buildroot should *not* take {C} into account, except for the list
of packages to include in Buildroot, which is fact of matter to {B}.

Buildroot, however, should catter for {B}, the users of Buildroot. And
this is achieved by having people in {A} implement some changes, and even
better, people moving from {B} to {A} to do the job. ;-)

What I mean is: some Buildroot users have complained that the root pasword
was not known (people in {B}). And the answer was to:
  - put it in the doc (IIRC), done by people in {A},
  - propose this change, also by people in {A},
so that people in {B} are no longer puzzled what to enter when prompted
for the root pasword.

Also, people in {A} may think of a whole new feature, and implement it,
without anything being asked for by people in {B} (but probably because
people in {A} are also in {B}, they have a need for that change).

In the end, if a change is deemed not fit for use by people in {B},
there is always the solution to revert that change (if enough of them
complain! ;-) )

> There are full featured
> distributions for most popular platforms that contain this kind of
> stuff. For true embedded developers, adding more things like this just
> complicate things, does not make it easier.

Well, true embedded developpers use their own skeleton, right? ;-)
(Just kidding).

Well, true embedded developpers (and I've been one for the ~14 past
years, now), know how to overcome what you see as a limitation. At least,
I (and it seems a few others as well) see it as an enhancement.

> I guess this is the sort of thing it would be good for the European
> Buildrooters to discuss at their next conference.

Yes. But this series has been floating for quite some time now:
    http://lists.busybox.net/pipermail/buildroot/2012-September/058583.html

But I'm afraid that it is in the end the role of the maintainer to decide
whether or not this feature is fit for inclusion or not. In this case,
it seems it was! ;-) (which does not mean it can't be reverted, either).

Regards,
Yann E. MORIN.

Patch

diff --git a/system/Config.in b/system/Config.in
index 5b66ac0..19bdd2d 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -12,27 +12,6 @@  config BR2_TARGET_GENERIC_ISSUE
        help
          Select system banner (/etc/issue) to be displayed at login.
 
-config BR2_TARGET_GENERIC_ROOT_PASSWD
-	string "Root password"
-	default ""
-	help
-	  Set the initial root password (in clear). It will be md5-encrypted.
-	  
-	  If set to empty (the default), then no root password will be set,
-	  and root will need no password to log in.
-	  
-	  WARNING! WARNING!
-	  Although pretty strong, MD5 is now an old hash function, and
-	  suffers from some weaknesses, which makes it susceptible to attacks.
-	  It is showing its age, so this root password should not be trusted
-	  to properly secure any product that can be shipped to the wide,
-	  hostile world.
-	  
-	  WARNING! WARNING!
-	  The password appears in clear in the .config file, and may appear
-	  in the build log! Avoid using a valuable password if either the
-	  .config file or the build log may be distributed!
-
 choice
 	prompt "/dev management"
 	default BR2_ROOTFS_DEVICE_CREATION_STATIC
@@ -140,6 +119,27 @@  endif
 
 if BR2_ROOTFS_SKELETON_DEFAULT
 
+config BR2_TARGET_GENERIC_ROOT_PASSWD
+	string "Root password"
+	default ""
+	help
+	  Set the initial root password (in clear). It will be md5-encrypted.
+	  
+	  If set to empty (the default), then no root password will be set,
+	  and root will need no password to log in.
+	  
+	  WARNING! WARNING!
+	  Although pretty strong, MD5 is now an old hash function, and
+	  suffers from some weaknesses, which makes it susceptible to attacks.
+	  It is showing its age, so this root password should not be trusted
+	  to properly secure any product that can be shipped to the wide,
+	  hostile world.
+	  
+	  WARNING! WARNING!
+	  The password appears in clear in the .config file, and may appear
+	  in the build log! Avoid using a valuable password if either the
+	  .config file or the build log may be distributed!
+
 config BR2_TARGET_GENERIC_GETTY_PORT
 	string "Port to run a getty (login prompt) on"
 	default "ttyS0"
diff --git a/system/system.mk b/system/system.mk
index 3c4d06e..651f7df 100644
--- a/system/system.mk
+++ b/system/system.mk
@@ -47,7 +47,9 @@  ifneq ($(TARGET_GENERIC_ISSUE),)
 TARGETS += target-generic-issue
 endif
 
+ifeq ($(BR2_ROOTFS_SKELETON_DEFAULT),y)
 TARGETS += target-root-passwd
+endif
 
 ifneq ($(TARGET_GENERIC_GETTY),)
 ifeq ($(BR2_ROOTFS_SKELETON_DEFAULT),y)