auto login / remote logins / multi user

[Stefan Sperling]

Hello,

comments made on IRC got me thinking about automatic login again.

Auto login would indeed be handy sometimes. Lately I got tired
of typing root and the well know "uClinux" password all over
again when trying to debug issues with the init scripts at boot
time.

The only problem I see with the current implementation of things
is that we'd lose the wonderful /etc/issue on bootup if we switched
from [/usr]/bin/agetty to /bin/sh in /etc/inittab. The obvious
workaround of having the shell issue file is trivial to implement
though.

Since telnetd (and presumably dropbear once we get the
server part working) do not use inittab but invoke
/bin/login or equivalent directly, this should not
affect remote logins. They will still prompt for a password.

This got me thinking about remote login security again.
The issue with remote logins is that the root
password cannot currently be changed at run time.
This is a wide open security hole for anyone being
spotted in a public network running DSLinux with
telnetd enabled, and propably dropbear in the future.

Being able to change the password would require
/etc/passwd to be writable.

This would make multi-user support available instantly.
Going multi-user would of course defeat auto login from
/etc/inittab again.

However, I don't see how we are going to have the passwd
file writable and at the same time protected from
unauthorised access on builds that use the FAT filesystem
for local storage. We can only set access permissions
globally on the FAT filesystem, which means either all
files are protected from non-root users or none at all.

I don't think people will be keen on recompiling their
images just to add a non-root user.

Dropping FAT filesystem support on CF/SD cards to get
around FAT filesystem limitations would lock out users
that either use Windows exclusively on their home machines
and are unwilling to use special ext2 tools to format
their CF/SD cards, or aren't willing to format their
CF/SD card to something other than FAT for compatilibity
reasons with other homebrew.

Offering a set of builds that support FAT but are
single user and insecure when running telnetd/dropbear 
and a set of builds that do not support FAT but are
secure and multi-user doubles the amount of builds we
have to maintain and compile. I really wouldn't like to
go down that road.

Another option would be to require people to format
their cards and create a FAT partition and a seperate
EXT2 partition in order to run DSLinux. This is the
solution I personally like best, but I already know
people will fill the forums with complaints if we do
that.

Does anyone have a good idea how to resolve this mess?

-- 
stefan
http://stsp.in-berlin.de                                 PGP Key: 0xF59D25F0