diff mbox series

rootfs-postcommands.bbclass: fix adding 'no password' banner

Message ID 20251128091606.3465381-1-Qi.Chen@windriver.com
State New
Headers show
Series rootfs-postcommands.bbclass: fix adding 'no password' banner | expand

Commit Message

ChenQi Nov. 28, 2025, 9:16 a.m. UTC 
From: Chen Qi <Qi.Chen@windriver.com>

It's possible that users use EXTRA_USERS_PARAMS to set password
for root or explicitly expire root password. So we need to check
these two cases to ensure the 'no password' banner is not misleading.

We need to ensure that the function runs after set_user_group function
from extrausers.bbclass. So change to use :append.

Besides the above check, the '\n' at the end of the banner is also
removed. The '\n' in /etc/issue means hostname instead of new line.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 meta/classes-recipe/rootfs-postcommands.bbclass | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Comments

Alexander Kanavin Nov. 28, 2025, 2:11 p.m. UTC | #1 
On Fri, 28 Nov 2025 at 10:16, Chen Qi via lists.openembedded.org
<Qi.Chen=windriver.com@lists.openembedded.org> wrote:
> It's possible that users use EXTRA_USERS_PARAMS to set password
> for root or explicitly expire root password. So we need to check
> these two cases to ensure the 'no password' banner is not misleading.

Wait. The check is for the 'empty-root-password' IMAGE_FEATURE, so is
your setup having that feature enabled, and then setting a root
password somewhere else anyway?

I'd say the correct thing to do is to refuse to set a password if the
feature is enabled. Can you show where and how it is done?

> We need to ensure that the function runs after set_user_group function
> from extrausers.bbclass. So change to use :append.

Why? What does the function do, and why this needs to run after?

> Besides the above check, the '\n' at the end of the banner is also
> removed. The '\n' in /etc/issue means hostname instead of new line.

Please do not bundle the unrelated changes, they should be all separate commits.

Alex
ChenQi Nov. 29, 2025, 3:43 a.m. UTC | #2 
Hi Alex,

Allowing 'empty-root-password' image feature + setting/expiring root password has been working for the past 10+ years. We should still allow it. In fact, we do.

Below is an example:
In conf/toolcfg.cfg:
OE_FRAGMENTS += "distro/poky core/yocto/root-login-with-empty-password
In local.conf:
INHERIT += "extrausers"
EXTRA_USERS_PARAMS += " passwd-expire root;"

The problem is that the banner is misleading when root has a password or is set to expire.

The solution of 'refusing to set a password for root' will send up as special cases in useradd_base.bbclass. I don't think this is an appropriate solution. And with doing this, we're breaking compatibility when unnecessary. 

The functions needs to run *after* set_user_group because this is where the root password is set or set to expire. The check is valid only after that.

I'll separate the '\n' change and send out V2.

Regards,
Qi


-----Original Message-----
From: Alexander Kanavin <alex.kanavin@gmail.com> 
Sent: Friday, November 28, 2025 10:11 PM
To: Chen, Qi <Qi.Chen@windriver.com>
Cc: openembedded-core@lists.openembedded.org; alex@linutronix.de
Subject: Re: [OE-core][PATCH] rootfs-postcommands.bbclass: fix adding 'no password' banner

On Fri, 28 Nov 2025 at 10:16, Chen Qi via lists.openembedded.org <Qi.Chen=windriver.com@lists.openembedded.org> wrote:
> It's possible that users use EXTRA_USERS_PARAMS to set password for 
> root or explicitly expire root password. So we need to check these two 
> cases to ensure the 'no password' banner is not misleading.

Wait. The check is for the 'empty-root-password' IMAGE_FEATURE, so is your setup having that feature enabled, and then setting a root password somewhere else anyway?

I'd say the correct thing to do is to refuse to set a password if the feature is enabled. Can you show where and how it is done?

> We need to ensure that the function runs after set_user_group function 
> from extrausers.bbclass. So change to use :append.

Why? What does the function do, and why this needs to run after?

> Besides the above check, the '\n' at the end of the banner is also 
> removed. The '\n' in /etc/issue means hostname instead of new line.

Please do not bundle the unrelated changes, they should be all separate commits.

Alex
diff mbox series

Patch

diff --git a/meta/classes-recipe/rootfs-postcommands.bbclass b/meta/classes-recipe/rootfs-postcommands.bbclass
index d3a569ba3e..3c4edc0301 100644
--- a/meta/classes-recipe/rootfs-postcommands.bbclass
+++ b/meta/classes-recipe/rootfs-postcommands.bbclass
@@ -4,8 +4,8 @@ 
 # SPDX-License-Identifier: MIT
 #
 
-# Zap the root password if empty-root-password feature is not enabled
-ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", "empty-root-password", "add_empty_root_password_note", "zap_empty_root_password ",d)}'
+# Zap the root password if empty-root-password feature is not enabled else add a 'no password' banner if appropriate
+ROOTFS_POSTPROCESS_COMMAND:append = ' ${@bb.utils.contains("IMAGE_FEATURES", "empty-root-password", "add_empty_root_password_note", "zap_empty_root_password ",d)}'
 
 # Allow dropbear/openssh to accept logins from accounts with an empty password string if allow-empty-password is enabled
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", "allow-empty-password", "ssh_allow_empty_password ", "",d)}'
@@ -259,7 +259,11 @@  zap_empty_root_password () {
 # This function adds a note to the login banner that the system is configured for root logins without password
 #
 add_empty_root_password_note () {
-	echo "Type 'root' to login with superuser privileges (no password will be asked).\n" >> ${IMAGE_ROOTFS}/etc/issue
+	rootpw="`grep '^root:' ${IMAGE_ROOTFS}/etc/shadow | cut -d':' -f2`"
+	rootpw_lastchanged="`grep "^root:" ${IMAGE_ROOTFS}/etc/shadow | cut -d: -f3`"
+	if [ -z "$rootpw" -a "$rootpw_lastchanged" != "0" ]; then
+		echo "Type 'root' to login with superuser privileges (no password will be asked)." >> ${IMAGE_ROOTFS}/etc/issue
+	fi
 }
 
 #