Post by Elie De Brauwer
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.
Post by Elie De Brauwer
"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:
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
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
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?
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.