skeleton: add default login port to /etc/securetty

From: Tzu-Jung Lee<[email protected]>

We ran into a "Login incorrect" problem when running the same rootfs image across platforms with different loging ports ttyS0/1/2/3.

Simply assignning "console" to BR2_TARGET_GENERIC_GETTY_PORT, which in turn modifies the /etc/inittab, is not enough because the "console" device was missing in the /etc/securetty.

While current securetty has enumerated a lot of ttys, this patch should save some efforts to enumerate more.

Change-Id Ifb1239c80eb86528345b24eb8d04b52b67aa1209

Signed-off-by Tzu-Jung Lee<[email protected]>

But perhaps it's even better to remove securetty completely? If it just
enumerates all possible ttys (even non-existent ones), it doesn't really add security... (Note: I haven't verified if util-linux's login allows root login if /etc/securetty is missing.)

Le Sat, 14 Jul 2012 18:56:51 +0200,
Arnout Vandecappelle<[email protected]> a ?crit :

Quoted 4 lines

But perhaps it's even better to remove securetty completely? If it just
enumerates all possible ttys (even non-existent ones), it doesn't really add security... (Note: I haven't verified if util-linux's login allows root login if /etc/securetty is missing.)

Or we just add the tty that is selected to have the getty on (i.e the skeleton would no longer have a etc/securetty file, and it would only be created with one entry, as done by the patch being discussed).

I wouldn't like that. I often use the default skeleton but override e.g.
inittab in the post-build script. I can't be bothered with setting BR2_TARGET_GENERIC_GETTY_PORT to empty. So the result is
that a /etc/securetty would be created which bears no relation with the actual login ports defined in inittab... And all this happens on the sly, without any consent from the user or warning in the config menus.

Bottom line: automatically adding BR2_TARGET_GENERIC_GETTY_PORT
to securetty is OK for me, but emptying it is not.

BTW I can't think of many circumstances where securetty makes sense
on an embedded system to begin with: why would you allow shell login on some port but not root login?

Le Sat, 14 Jul 2012 23:20:50 +0200,
Arnout Vandecappelle<[email protected]> a ?crit :

Quoted 7 lines

I wouldn't like that. I often use the default skeleton but override e.g.
inittab in the post-build script. I can't be bothered with setting BR2_TARGET_GENERIC_GETTY_PORT to empty. So the result is
that a /etc/securetty would be created which bears no relation with the actual login ports defined in inittab... And all this happens on the sly, without any consent from the user or warning in the config menus.

Quoted 2 lines

Bottom line: automatically adding BR2_TARGET_GENERIC_GETTY_PORT
to securetty is OK for me, but emptying it is not.

Hmm, ok. But if you're modifying the inittab through a post-build script, we could also say that it's your responsibility to also adjust /etc/securetty accordingly, no?

I don't have a strong opinion here, just trying to find the right balance.

Quoted 3 lines

BTW I can't think of many circumstances where securetty makes sense
on an embedded system to begin with: why would you allow shell login on some port but not root login?

Is removing /etc/securetty sufficient? Both for Busybox getty, the full-featured getty, and things like dropbear, openssh, telnet and al? I think telnet needs pts/[0-n] to be in /etc/securetty otherwise it doesn't allow root login.

Quoted 13 lines · Thomas Petazzoni

Le Sat, 14 Jul 2012 23:20:50 +0200,
Arnout Vandecappelle<[email protected]> a ?crit :

Quoted 9 lines

I wouldn't like that. I often use the default skeleton but override
e.g.
inittab in the post-build script. I can't be bothered with setting BR2_TARGET_GENERIC_GETTY_PORT to empty. So the result is that a /etc/securetty would be created which bears no relation with the actual login ports defined in inittab... And all this happens on the
sly, without any consent from the user or warning in the config menus.

Quoted 6 lines

Quoted 2 lines

Bottom line: automatically adding BR2_TARGET_GENERIC_GETTY_PORT
to securetty is OK for me, but emptying it is not.

Hmm, ok. But if you're modifying the inittab through a post-build script, we could also say that it's your responsibility to also adjust /etc/securetty accordingly, no?

Maybe, but if the securetty file isn't even part of the skeleton it's less
obvious. But more importantly: people will send questions to the mailing list asking why they can't log in into their buildroot system...

Quoted 10 lines

I don't have a strong opinion here, just trying to find the right balance.

Quoted 3 lines

BTW I can't think of many circumstances where securetty makes sense
on an embedded system to begin with: why would you allow shell login on some port but not root login?

Is removing /etc/securetty sufficient? Both for Busybox getty, the full-featured getty, and things like dropbear, openssh, telnet and al? I think telnet needs pts/[0-n] to be in /etc/securetty otherwise it doesn't allow root login.

I did a search for securetty in a build of an allyesconfig, and only found
it in
util-linux and busybox. And I verified (by source code inspection) that util-linux
accepts an absent securetty.

pam has a securetty module, but we don't support pam yet. And anyway:
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l113>
if (stat(SECURETTY_FILE, &ttyfileinfo)) {
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l114>
pam_syslog(pamh, LOG_NOTICE, "Couldn't open %s: %m", SECURETTY_FILE);
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l115>
return PAM_SUCCESS; /* for compatibility with old securetty handling,
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l116>
this needs to succeed. But we still log the
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l117>
error. */
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l118>
}

Change-Id: Ifb1239c80eb86528345b24eb8d04b52b67aa1209

+ifneq ($(TARGET_GENERIC_GETTY), )

From: Tzu-Jung Lee <[email protected]>

We ran into a "Login incorrect" problem when running the same rootfs image across platforms with different loging ports ttyS0/1/2/3.

Simply assignning "console" to BR2_TARGET_GENERIC_GETTY_PORT, which in turn modifies the /etc/inittab, is not enough because the "console" device was missing in the /etc/securetty.

While current securetty has enumerated a lot of ttys, this patch should save some efforts to enumerate more.

Signed-off-by Tzu-Jung Lee <[email protected]>

Signed-off-by Spenser Gilliland <[email protected]>

Acked-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

---
 support/scripts/graph-depends |    1 +
 system/system.mk              |    8 ++++++++
 2 files changed, 9 insertions(+)

support/scripts/graph-depends +1 -0

index 50b8670..ac24086 100755
@@ -161,6 +161,7 @@ def remove_redundant_deps(deps):
     return newdeps
 
 TARGET_EXCEPTIONS = [
+    "target-generic-securetty",
     "target-generic-issue",
     "target-generic-getty-busybox",
     "target-generic-do-remount-rw",

system/system.mk +8 -1

index 44a33ae..3e11a51 100644
@@ -9,6 +9,10 @@ TARGET_GENERIC_GETTY:=$(call qstrip,$(BR2_TARGET_GENERIC_GETTY_PORT))
 TARGET_GENERIC_GETTY_BAUDRATE:=$(call qstrip,$(BR2_TARGET_GENERIC_GETTY_BAUDRATE))
 TARGET_GENERIC_GETTY_TERM:=$(call qstrip,$(BR2_TARGET_GENERIC_GETTY_TERM))
 
+target-generic-securetty:
+       grep -q ^$(TARGET_GENERIC_GETTY)$$ $(TARGET_DIR)/etc/securetty || \
+               echo $(TARGET_GENERIC_GETTY) >> $(TARGET_DIR)/etc/securetty
+
 target-generic-hostname:
        mkdir -p $(TARGET_DIR)/etc
        echo "$(TARGET_GENERIC_HOSTNAME)" > $(TARGET_DIR)/etc/hostname

@@ -40,6 +44,10 @@ target-generic-do-remount-rw:
 target-generic-dont-remount-rw:
        $(SED) '/^[^#].*# REMOUNT_ROOTFS_RW$$/s~^~#~' $(TARGET_DIR)/etc/inittab
 
+ifneq ($(TARGET_GENERIC_GETTY),)
+TARGETS += target-generic-securetty
+endif
+
 ifneq ($(TARGET_GENERIC_HOSTNAME),)
 TARGETS += target-generic-hostname
 endif
--

1.7.9.5

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Spenser" == Spenser Gilliland <[email protected]> writes: