Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] skeleton: add default login port to /etc/securetty
Date: Sat, 14 Jul 2012 23:20:50 +0200	[thread overview]
Message-ID: <5001E2B2.6070509@mind.be> (raw)
In-Reply-To: <20120714191530.539ca71c@skate>

On 07/14/12 19:15, Thomas Petazzoni wrote:
> Le Sat, 14 Jul 2012 18:56:51 +0200,
> Arnout Vandecappelle<arnout@mind.be>  a ?crit :
>
> >    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?

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

  reply	other threads:[~2012-07-14 21:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-13  3:19 [Buildroot] [PATCH 1/1] skeleton: add default login port to /etc/securetty roylee17 at gmail.com
2012-07-14 16:56 ` Arnout Vandecappelle
2012-07-14 17:15   ` Thomas Petazzoni
2012-07-14 21:20     ` Arnout Vandecappelle [this message]
2012-07-14 23:08       ` Thomas Petazzoni
2012-07-15  0:28         ` Arnout Vandecappelle
2012-07-30 15:13           ` Tzu-Jung Lee
2013-05-26 20:14 ` Spenser Gilliland
2013-05-26 20:30   ` Thomas Petazzoni
2013-05-26 20:40   ` Spenser Gilliland
2013-05-26 20:43     ` Spenser Gilliland
2013-05-26 21:00     ` Peter Korsgaard
  -- strict thread matches above, loose matches on Subject: below --
2013-05-21  9:56 Tzu-Jung Lee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5001E2B2.6070509@mind.be \
    --to=arnout@mind.be \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox