[CHANGE PROPOSAL] The securetty file is empty by default

Daniel P. Berrange berrange at redhat.com
Thu Apr 10 09:30:50 UTC 2014


On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote:
> On Wed, 02.04.14 09:12, quickbooks office (quickbooks.office at gmail.com) wrote:
> 
> > [CHANGE PROPOSAL] The securetty file is empty by default
> > 
> > All the info has been sitting here @
> > https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default
> > since March 20th.
> > 
> > Did I mess something up? Or is there just a backlog?
> 
> This sounds entirely backwards, and I'd instead vote for removing
> securetty from the PAM stacks we ship altogether. The concept is
> outdated. It was useful in a time where the primary way to access a
> server was via physically attached TTY devices. But that time is mostly
> over...
> 
> Nowadays the device names exposed by the kernel tend to be dynamically
> assigned, they should not be assumed stable (with one exeption, classic
> UART 16650 serial ports). Stable paths for these devices we add in via
> symlinks these days, using /dev/*/by-path/, /dev/*/by-id/, -- as you
> might know from disk devices. Now, the securetty logic is unable to
> verify things using these symlinks, hence the entire concept is
> flawed. It will use an unsteable device name instead, making it mostly
> useless in hotplug scenarios.
> 
> securetty is particularly annoying when we use containers. Tools like
> "machinectl login" will dynamically spawn a getty for you on a pts
> device in the container, but since pts is not listed in securetty you
> cannot log in as root by default. And you cannot event add a wildcard
> match of pts/* to it, to make this work nicely.

Yep, the securetty file is one of only 2 remaining blockers for getting
login working out of the box in containers. Removing securetty would be a
great help there given the inability to wildcard pts/*. The other problem
is of course the horrible pam audit module, which the kernel guys are
hopefully working towards a solution for.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


More information about the devel mailing list