Message ID | 1f2432a8027f1e1c780a45b488be8be03f1b1b93.1357397453.git.yann.morin.1998@free.fr |
---|---|
State | Accepted |
Commit | b98b191b5cb628ed8dd32236c4b08d025b65941f |
Headers | show |
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
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.
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)
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(-)