[Toybox] New toy: login

[Rob Landley]

On 04/28/2012 07:42 AM, Elie De Brauwer wrote:
> On 04/26/2012 07:24 AM, Rob Landley wrote:
>>> Well I'm just listing what I saw appear either in the shadow sources
>>> or the busybox code. Personally I think PAM support is the most useful
>>>   of the list above and a likely candidate for a follow up patch.
>>
>> PAM lets you log in from a a windows server, which lots of people like,
>> so yeah. But I vaguely recall there was a busybox FAQ many moons ago
>> saying that PAM support was a question of building against a library
>> that supported it (glibc did, uclibc didn't), and that busybox didn't
>> actually have to do anything specific to support it.
>>
>> But I didn't actually look at the code (or if I did it was long enough
>> ago I don't remember).
> 
> Well, login now reads a password, hashes it, and compares the hash with
> what passwd/shadow have to say.  When you use pam, you just ask pam to
> take care of it (so you replace the passwd/shadow part with some pam
> calls), the advantage is that all the PAM stuff is something which can
> be dealt with system wide and doesn't care which application is calling
> it. The only thing is that you need to have this PAM dialog set up and
> you need to link with libpam (busybox supports this through login, but
> buildroot doesn't allow you to create a pam-aware rootfs).

I thought it was more transparent than this, but alas anything designed
by Red Hat is going to look like it was dun by Sun anyway, so I
shouldn't be surprised.

>> "This has X" != "we need to add X".
>>
>> Given that ssh doesn't use login, serial consoles don't use login, and
>> distros boot straight into X, this is not hugely useful code today. (I'm
>> pretty sure smartphones don't have VGA ttys.)
> 
> Afaik, inittab typically spawns getty and friends, and getty spawns
> login by default to authenticate users. And getty is spawned on both vga
> consoles and serial consoles. I wouldn't want to put a dollar on a table
> for each login running over a uart on an embedded board.

Distros mostly don't use sysv init anymore. I'm not saying upstart or
systemd are improvements, they're basically both attempts to squeeze
parallelism out of the boot process in response to an IBM engineer who
(back in 2003) showed how to boot a system using "make -j" to run the
init scripts, resolving dependencies between them:

http://lwn.net/Articles/50115/

Then Lennart Pottering got involved and it was "let's disrupt
everything, tradition is bad, let's not even call it unix anymore, you
must relearn everything, we can't be _compatible_..." and so on.
(Imagine if Plan 9 _hadn't_ been done by Ken Thompson, where at least
everybody trusted his judgement because it's guaranteed to be brilliant
and simple.)

I did "oneit" which basically runs a single monolithic application
(generally a shell prompt) with a controlling tty and zombie reaping,
with the system shutting down cleanly when it exits. I.E. the simplest
possible general-purpose init program.

I haven't done a sysv init, nor an upstart/systemd replacement yet,
because I need to do more research on what people actually _need_ here.
 (I can do a sysv init, yes. I completely rewrote the one in busybox
circa 2005 although it got lost in the migration from cvs to svn. The
question is should I?)

Let's back up:

In some ways, login is the opposite of sudo. You run as root and drop
down to a specific user, limiting access. It prompts for which user,
prompts for a password, and execs their shell entry out of /etc/passwd
if they match.

I not that the "su" command is related to this. Select user, prompt for
password, and then run their command line _through_the_login_shell_ (ala
-c 'remaining command line arguments'). Thus you can filter what the
user is allowed to do, by giving them /bin/false which doesn't care what
the rest of the command line says.

It's really sad that shells have the "-c ONEARG" syntax instead of
working like nice, detach, sudo, netcat... some way to specify
"everything after this point is a new command line", so you can just
exec the thing without reparsing the spaces and punctuation. It's a
security nightmare trying to get that reliable, and a huge amount of
unnecessary work.  i mean I can go:

  sudo ls -l

But I can't go

  sh ls -l

Sigh...

Anyway, given that the central idea behind login is "confirm
credentials, switch to a user, run their shell"... this is why I give
funny looks to things like /etc/issue which... really aren't part of
that. It seems like historical cruft accumulated over the years, not
doing one thing and doing it well. In the absence of a spec, how do I
draw boundaries around this command?

Rob

P.S. My cold's flared back up again, due to ill-advised packing where I
spent a couple hours doing heavy lifting while breathing dust. So if I
seem a little incoherent right now, it's because I am.
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

 1335645005.0