[PATCH] added 'isar-cfg-userpw' package

[claudius....@siemens.com]

From: Claudius Heine <c...@denx.de>

With this package setting of arbitrary user passwords should be
possible.

To do this use the 'CFG_USER_PW' variable as described in the user
manual.

Signed-off-by: Claudius Heine <c...@denx.de>
---
doc/user_manual.md | 1 +
meta-isar/conf/local.conf.sample | 2 ++
meta/classes/isar-image.bbclass | 2 +-
.../isar-cfg-userpw/files/postinst.tmpl | 15 ++++++++++++
.../isar-cfg-userpw/isar-cfg-userpw.bb | 23 +++++++++++++++++++
5 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-support/isar-cfg-userpw/files/postinst.tmpl
create mode 100644 meta/recipes-support/isar-cfg-userpw/isar-cfg-userpw.bb

diff --git a/doc/user_manual.md b/doc/user_manual.md
index db0bf85..53bb36a 100644
--- a/doc/user_manual.md
+++ b/doc/user_manual.md
@@ -328,6 +328,7 @@ Some other variables include:
- `DISTRO_APT_PREMIRRORS` - The preferred mirror (append it to the default URI in the format `ftp.debian.org my.preferred.mirror`. This variable is optional.
- `CFG_ROOT_PW` - The encrypted root password to be set. To encrypt password use `mkpasswd`. You find `mkpasswd` in the `whois` package of Debian. If the variable is empty, root login is passwordless.
- `CFG_ROOT_LOCKED` - If set to `1` the root account will be locked.
+ - `CFG_USER_PW` - A space separated list of user names and encrypted passwords separated by a colon. (e.g. `username1:encryptedpw1 username2:encryptedpw2`)

---

diff --git a/meta-isar/conf/local.conf.sample b/meta-isar/conf/local.conf.sample
index e5827aa..494a283 100644
--- a/meta-isar/conf/local.conf.sample
+++ b/meta-isar/conf/local.conf.sample
@@ -178,3 +178,5 @@ ISAR_CROSS_COMPILE ?= "0"
# mkpasswd -m sha512crypt -R 10000
# mkpasswd is part of the 'whois' package of Debian
CFG_ROOT_PW ?= "$6$rounds=10000$RXeWrnFmkY$DtuS/OmsAS2cCEDo0BF5qQsizIrq6jPgXnwv3PHqREJeKd1sXdHX/ayQtuQWVDHe0KIO0/sVH8dvQm1KthF0d/"
+# Set user 'isar' password to 'isar':
+CFG_USER_PW ?= "isar:$6$rounds=10000$WMnSt8s9nLE$M/0eQVs0f05VpW8uzscs54GUwzhh/gjN3Vb85QEIIh1XihyvE.Xw4reJSxHqWcP0I0CnllKhseg6SRcGIIx7P1"
diff --git a/meta/classes/isar-image.bbclass b/meta/classes/isar-image.bbclass
index cdd1651..0100d0b 100644
--- a/meta/classes/isar-image.bbclass
+++ b/meta/classes/isar-image.bbclass
@@ -17,7 +17,7 @@ SRC_URI += "${@ cfg_script(d) }"

DEPENDS += "${IMAGE_INSTALL} ${IMAGE_TRANSIENT_PACKAGES}"

-IMAGE_TRANSIENT_PACKAGES += "isar-cfg-localepurge isar-cfg-rootpw"
+IMAGE_TRANSIENT_PACKAGES += "isar-cfg-localepurge isar-cfg-rootpw isar-cfg-userpw"

WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}"

diff --git a/meta/recipes-support/isar-cfg-userpw/files/postinst.tmpl b/meta/recipes-support/isar-cfg-userpw/files/postinst.tmpl
new file mode 100644
index 0000000..47fffd0
--- /dev/null
+++ b/meta/recipes-support/isar-cfg-userpw/files/postinst.tmpl
@@ -0,0 +1,15 @@
+#!/bin/sh
+set -e
+
+USER_ENTRIES='${CFG_USER_PW} '
+
+while true; do
+ USER_ENTRY="${USER_ENTRIES%% *}" # First element of list
+ USER_ENTRIES="${USER_ENTRIES#${USER_ENTRY} }" # Rest of list
+
+ if [ -z "${USER_ENTRY}" ]; then
+ break
+ fi
+
+ printf '%s' "${USER_ENTRY}" | chpasswd -e
+done
diff --git a/meta/recipes-support/isar-cfg-userpw/isar-cfg-userpw.bb b/meta/recipes-support/isar-cfg-userpw/isar-cfg-userpw.bb
new file mode 100644
index 0000000..75b0446
--- /dev/null
+++ b/meta/recipes-support/isar-cfg-userpw/isar-cfg-userpw.bb
@@ -0,0 +1,23 @@
+# This software is a part of ISAR.
+
+DESCRIPTION = "Isar configuration package for user passwords"
+MAINTAINER = "isar-users <isar-...@googlegroups.com>"
+DEBIAN_DEPENDS = "passwd"
+
+SRC_URI = "file://postinst.tmpl"
+
+TEMPLATE_FILES = "postinst.tmpl"
+TEMPLATE_VARS = "CFG_USER_PW"
+
+CFG_USER_PW ?= ""
+
+python() {
+ # Enforce CFG_USER_PW to be a single space separated array
+ d.setVar("CFG_USER_PW", " ".join(d.getVar("CFG_USER_PW", True).split()))
+}
+
+inherit dpkg-raw
+
+do_install() {
+ echo "intentionally left blank"
+}
--
2.20.1

[Henning Schild]

Thanks for looking into that, good addition to the root-PW story!

Am Mon, 18 Feb 2019 17:21:13 +0100
schrieb "[ext] claudius....@siemens.com"
<claudius....@siemens.com>:

We should fail hard if someone (ab)uses this to set the root-password.

Henning

[Henning Schild]

In fact we might just fold the root logic and this together and have
just one package. The code is so fresh we will hardly offend anyone
already using it.

Henning

[Jan Kiszka]

Missed this until I had to deal with it: This does not allow per-image password
configuration because there is only one, hard-coded isar-cfg-userpw package that
all images pull. E.g., how to build a release (root account locked) and a debug
image (well-known insecure or empty password) at the same time now?

We rather need to change the logic to pass the control variables from the host
down into the chroot during installation where the transient package can then
evaluate them. Or model this - as a special case - without a package.

Before the release, we should at least prove if the current recipe interface can
be maintained with the above requirement, so that we do not break it again right
after that.

Jan

[Jan Kiszka]

The same conceptual issue applies to isar-cfg-localepurge: LOCALE_GEN and
LOCALE_DEFAULT should be configurable on a per-image basis, not a per-build.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[Claudius Heine]

Hi Jan,

Quoting Jan Kiszka (2019-02-25 09:07:35)

You are right! I haven't considered that.

Normally you would not have a 'debug' image and a 'release' image, but
different multi/local configurations for that. Having debug images and
release images is a anti-pattern for bb based projects IMO and should
not be done in Isar.

But of course if you now have a '*-debug' and '*-release' multiconfig,
you cannot build that in parallel if one package is build with two
different variables.

And that exactly hits the mark with the problem I have with the way Isar
uses multiconfigs and tries to share packages from different
multiconfigs.

IMO if you want to continue doing it that way, you would need to have a
'isar-cfg-localpurge-debug' and a 'isar-cfg-userpw-debug'. And do that
for all possible other configurations you want to build in parallel...

Cheers,
Claudius

>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

> --
> You received this message because you are subscribed to the Google Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+...@googlegroups.com.
> To post to this group, send email to isar-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/683245f8-e5f0-38b8-0532-94170db742fe%40siemens.com.
> For more options, visit https://groups.google.com/d/optout.

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de

PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
Keyserver: hkp://pool.sks-keyservers.net

[Jan Kiszka]

This is not true. In the end, you will always have two images of that kind,
often defined by different package sets, set in the respective image recipes.

>
> But of course if you now have a '*-debug' and '*-release' multiconfig,
> you cannot build that in parallel if one package is build with two
> different variables.
>
> And that exactly hits the mark with the problem I have with the way Isar
> uses multiconfigs and tries to share packages from different
> multiconfigs.
>
> IMO if you want to continue doing it that way, you would need to have a
> 'isar-cfg-localpurge-debug' and a 'isar-cfg-userpw-debug'. And do that
> for all possible other configurations you want to build in parallel...

Awkward. We need to stop this weird patterns which require too much boilerplate
recipes to achieve very simple things. Let's just make these variables per-image.

[Henning Schild]

Am Mon, 25 Feb 2019 09:48:38 +0100
schrieb "[ext] Jan Kiszka" <jan.k...@siemens.com>:

I had a feeling that same PN-PV but different content could be a
problem. And here we go. But Claudius is right, either we have
different packages (by name and/or version) or we do not use packages
for such tasks. Per Image variables will not work, the last
do_deploy_deb will win and set the password for every image sharing the
repo.

Henning

> Jan
>

[Adler, Michael]

Just a heads-up, I'm having some issues with this package:

==============================SNIP START=======================================
NOTE: Executing RunQueue Tasks
ERROR: mc:qemuamd64-stretch:isar-cfg-rootpw-1.0-r0 do_build: Function failed: do_build (log file is located at /work/build/tmp/work/debian-stretch-amd64/isar-cfg-rootpw-1.0-r0/temp/log.do_build.179)
ERROR: Logfile of failure stored in: /work/build/tmp/work/debian-stretch-amd64/isar-cfg-rootpw-1.0-r0/temp/log.do_build.179
Log data follows:
| DEBUG: Executing shell function do_build
| This script can only be run as root:root or builder:builder!
| (Currently running as builder(1000):users(100))
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_build (log file is located at /work/build/tmp/work/debian-stretch-amd64/isar-cfg-rootpw-1.0-r0/temp/log.do_build.179)
ERROR: Task (multiconfig:qemuamd64-stretch:/work/isar/meta/recipes-support/isar-cfg-rootpw/isar-cfg-rootpw.bb:do_build) failed with exit code '1'
==============================SNIP END =======================================

My setup:

- NixOS (most notably: uid=1000, gid=100, uid != gid)
- Isar runs inside a Docker image (kasproject/kas-isar)

However I could imagine that this also breaks in native mode as soon as uid != gid (though I will not attempt to run Isar natively). Any ideas?

Kind regards,
Michael

--
Michael Adler
Siemens AG, Corporate Technology, CT RDA IOT SES-DE, Otto-Hahn-Ring 6, 81739 Munich, Germany

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

[Henning Schild]

Hi,

this is not related to the package. But to any package that goes
through common.sh and checks the ids.

https://groups.google.com/forum/#!searchin/isar-users/Align$20UID$20and$20GID$20%7Csort:date/isar-users/S5W8D3X4Lkg/n7HbASWnAwAJ

The result of this discussion was that we probably need to align the
ids and hope we never get in trouble with the host. In this case we do!

The alignment should be changed. If the group does exist (100) join the
user and do not try and create a group. The check should be changed to
make sure the gid is the main group gid, instead of 1000.

Henning

Am Mon, 25 Feb 2019 10:18:52 +0000
schrieb "[ext] Adler, Michael" <michae...@siemens.com>:

[Jan Kiszka]

Right, we need to discuss about that "everything is a package" in this context.
I may make Isar life easier, but not Isar user's life. Also, it's deviating with
the image configuration from OE.

[Claudius Heine]

Quoting Jan Kiszka (2019-02-25 09:48:38)

> On 25.02.19 09:44, Claudius Heine wrote:
> > Quoting Jan Kiszka (2019-02-25 09:07:35)
> >> On 23.02.19 11:42, Jan Kiszka wrote:

[..]

> >>> Missed this until I had to deal with it: This does not allow per-image password
> >>> configuration because there is only one, hard-coded isar-cfg-userpw package that
> >>> all images pull. E.g., how to build a release (root account locked) and a debug
> >>> image (well-known insecure or empty password) at the same time now?
> >>>
> >>> We rather need to change the logic to pass the control variables from the host
> >>> down into the chroot during installation where the transient package can then
> >>> evaluate them. Or model this - as a special case - without a package.
> >>>
> >>> Before the release, we should at least prove if the current recipe interface can
> >>> be maintained with the above requirement, so that we do not break it again right
> >>> after that.
> >>>
> >>
> >> The same conceptual issue applies to isar-cfg-localepurge: LOCALE_GEN and
> >> LOCALE_DEFAULT should be configurable on a per-image basis, not a per-build.
> >
> > You are right! I haven't considered that.
> >
> > Normally you would not have a 'debug' image and a 'release' image, but
> > different multi/local configurations for that. Having debug images and
> > release images is a anti-pattern for bb based projects IMO and should
> > not be done in Isar.
>
> This is not true. In the end, you will always have two images of that kind,
> often defined by different package sets, set in the respective image recipes.

Then we have to think hard about where the configuration of root file
systems should belong. Because that is what we have to solve generally
and not for just this recipe. Because all of that could be different in
a 'debug' image.

We have sshd, ntpd, network, user, locale, ... and of course the
configuration for every custom package to consider. If those should not
be placed in one or more debian packages, and not be updatable over the
repositories, then we need some good interface in the image class, that
works well with the bitbake layering, execution order and task mechanic,
to solve that. Currently I cannot think of a good way to solve that.

>
> >
> > But of course if you now have a '*-debug' and '*-release' multiconfig,
> > you cannot build that in parallel if one package is build with two
> > different variables.
> >
> > And that exactly hits the mark with the problem I have with the way Isar
> > uses multiconfigs and tries to share packages from different
> > multiconfigs.
> >
> > IMO if you want to continue doing it that way, you would need to have a
> > 'isar-cfg-localpurge-debug' and a 'isar-cfg-userpw-debug'. And do that
> > for all possible other configurations you want to build in parallel...
>
> Awkward. We need to stop this weird patterns which require too much boilerplate
> recipes to achieve very simple things. Let's just make these variables per-image.

Yes, it is very awkward. But that is how we would need to do it to have
multiple different configurations in one tmpdir with the current Isar
design.

regards,
Claudius

[Henning Schild]

One workaround for you would be to have your user in a user-group with
a gid that it not yet taken in a fresh debian container, like most
other distros default to today.

Henning

Am Mon, 25 Feb 2019 11:34:06 +0100
schrieb "[ext] Henning Schild" <henning...@siemens.com>:

[Claudius Heine]

Quoting Jan Kiszka (2019-02-25 12:15:32)

> On 25.02.19 10:32, Henning Schild wrote:
> > Am Mon, 25 Feb 2019 09:48:38 +0100
> > schrieb "[ext] Jan Kiszka" <jan.k...@siemens.com>:
> >> On 25.02.19 09:44, Claudius Heine wrote:

[...]

> >>> But of course if you now have a '*-debug' and '*-release'
> >>> multiconfig, you cannot build that in parallel if one package is
> >>> build with two different variables.
> >>>
> >>> And that exactly hits the mark with the problem I have with the way
> >>> Isar uses multiconfigs and tries to share packages from different
> >>> multiconfigs.
> >>>
> >>> IMO if you want to continue doing it that way, you would need to
> >>> have a 'isar-cfg-localpurge-debug' and a 'isar-cfg-userpw-debug'.
> >>> And do that for all possible other configurations you want to build
> >>> in parallel...
> >>
> >> Awkward. We need to stop this weird patterns which require too much
> >> boilerplate recipes to achieve very simple things. Let's just make
> >> these variables per-image.
> >
> > I had a feeling that same PN-PV but different content could be a
> > problem. And here we go. But Claudius is right, either we have
> > different packages (by name and/or version) or we do not use packages
> > for such tasks. Per Image variables will not work, the last
> > do_deploy_deb will win and set the password for every image sharing the
> > repo.
>
> Right, we need to discuss about that "everything is a package" in this context.
> I may make Isar life easier, but not Isar user's life. Also, it's deviating with
> the image configuration from OE.

I now took a look exactly how OE manage that, and that seems to answer
my previous question. The implementation seems a bit complex, but I
guess that it could be adapted to fit Isars purposes.

regards,
Claudius

[Jan Kiszka]

On 25.02.19 11:34, [ext] Henning Schild wrote:
> Hi,
>
> this is not related to the package. But to any package that goes
> through common.sh and checks the ids.
>
> https://groups.google.com/forum/#!searchin/isar-users/Align$20UID$20and$20GID$20%7Csort:date/isar-users/S5W8D3X4Lkg/n7HbASWnAwAJ
>
> The result of this discussion was that we probably need to align the
> ids and hope we never get in trouble with the host. In this case we do!
>
> The alignment should be changed. If the group does exist (100) join the
> user and do not try and create a group. The check should be changed to
> make sure the gid is the main group gid, instead of 1000.

FWIW, just ran into the same issue after purging my build folder and retrying a
clean "kas-docker --isar build". I'm not seeing it with jailhouse-images where
we do not use kas-docker yet and also do not create the build folder outside of
the container, thus with host IDs.

So, this needs to be fixed in our kas-isar container, I suppose...

Jan

[Jan Kiszka]

On 26.02.19 20:36, [ext] Jan Kiszka wrote:
> On 25.02.19 11:34, [ext] Henning Schild wrote:
>> Hi,
>>
>> this is not related to the package. But to any package that goes
>> through common.sh and checks the ids.
>>
>> https://groups.google.com/forum/#!searchin/isar-users/Align$20UID$20and$20GID$20%7Csort:date/isar-users/S5W8D3X4Lkg/n7HbASWnAwAJ
>>
>>
>> The result of this discussion was that we probably need to align the
>> ids and hope we never get in trouble with the host. In this case we do!
>>
>> The alignment should be changed. If the group does exist (100) join the
>> user and do not try and create a group. The check should be changed to
>> make sure the gid is the main group gid, instead of 1000.
>
> FWIW, just ran into the same issue after purging my build folder and retrying a
> clean "kas-docker --isar build". I'm not seeing it with jailhouse-images where
> we do not use kas-docker yet and also do not create the build folder outside of
> the container, thus with host IDs.
>
> So, this needs to be fixed in our kas-isar container, I suppose...

No, the bug is really in common.sh, the container is fine:

That script checks for group names, which is probably pointless. In this case,
we are in the right group, that group just has an alias called "builder", but
was originally called "users".

Why the heck should we check the group?

Jan

[Henning Schild]

Because that is the most conservative we can get to check the complete
file ownership. I guess we should keep checking the group but just make
sure the the current gid is the gid of the user.

- [ "$(id -gn)" != "builder" ]
+ [ "$(id -g)" != "$(id -g builder)"

... same for root.

Henning

> Jan
>

[Henning Schild]

On Wed, 27 Feb 2019 09:46:05 +0100

"[ext] Henning Schild" <henning...@siemens.com> wrote:

Patch is on the way ...

Henning

> Henning
>
> > Jan
> >
>

[Claudius Heine]

Hi,

Well the exact implementation in OE might be a bit to much, since that
is part of meta/lib/oe/rootfs.py and that leads down into a rabbit hole
very fast.

So that will have to be implemented mostly new for Isar.