Discussion:
New toy: login
(too old to reply)
Elie De Brauwer
2012-04-24 21:16:07 UTC
Permalink
Hello world,

In attachment you can find an initial version of login. For the moment
still rather basic, it supports:
- shadow passwords
- /etc/nologon
- /etc/motd
- passwd style account locking
It requires linking with glibc's crypt (for crypt()) for now.

It does not support pam/securetty/ etc/issue / selinux/utmp yet.
Btw, it contains several functions which are candidates for reuse for
other tools which relate to user management. These functions will be put
common once the need for that becomes clear.

I've just tested this on my system without much special things present,
so there's some room for testing on more 'special' cases.

Comments welcome.

my 2 cents
E.
--
Elie De Brauwer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: login.patch
Type: text/x-patch
Size: 8211 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120424/506d6887/attachment.bin>
Rob Landley
2012-04-25 02:18:38 UTC
Permalink
Post by Elie De Brauwer
Hello world,
In attachment you can find an initial version of login. For the moment
- shadow passwords
- /etc/nologon
- /etc/motd
- passwd style account locking
It requires linking with glibc's crypt (for crypt()) for now.
Applied, but with reservations.

Specifically, you add three new headers, one of which is in susv4
(syslog.h) and two of which aren't (crypt.h and shadow.h).

This implies we should have another config time probe in
scripts/genconfig.sh to go with the unshare() probe, setting some kind
of symbol (TOYBOX_CSHADOW) that login can depend on the way unshare does
now. We can do one probe for both crypt and shadow, I'm not sure making
shadow configurable in 2012 buys us much. World readable /etc/passwd is
obsolete.

Probably also good to make the new --as-needed stanza be conditionally
added to some sort of $AS_NEEDED evironment variable, and used through
that on the compiler command line. (I dunno what the compiler does on
systems that haven't got -lcrypt, I thin even with --as-needed that's a
build break if the library isn't found. I know glibc and uClibc can
provide this, not sure about musl, who knows about macosx and I still
haven't got a bionic test environment set up. So yeah, not in susv4 or
implies a probe when it comes to headers.)
Post by Elie De Brauwer
It does not support pam/securetty/ etc/issue / selinux/utmp yet.
Not hugely bothered by the lack of any of that. I vaguely recall pam
support is mostly libc's problem, and selinux is _entirely_ Red Hat's
problem

(<rant type="selinux">If you want to run PHEL (Pointy Hair Enterprise
Linux), you know where to find it. I can be talked out of this position,
but am waiting for actual users to show up before caring. Making the
system more COMPLICATED is not the same as making it more SECURE. Secure
works like waterproof. Clueless bureaucrats tend to confuse availability
with security: clustering with heartbeat and failover may keep the
system up through lightning strikes but doesn't keep the right data in
and the wrong data out. Geographic distribution makes security _harder_,
but it _does_ increase the price tag, which makes the pointy-haired
happy in a "something must be done, this is something, therefore it must
be done" way. </rant>)

Isn't /etc/issue your shell profile's problem (or is that motd)?

I note that multi-user shared server systems aren't really the common
case anymore. (When that _does_ happen it generally involves a vm or
containers these days.) The real advantage of a multi-user OS these days
is your programs can have roles so your web browser can't format your
hard drive without a password. That's valuable, but doesn't involve
friendly little notes from the sysadmin. If you've got one, they can
email you.

As for utmp, that might be implicitly required by susv4, but a quick
glance isn't finding it. ("who" is querying pty/tty, not login
records.) I don't actually remember what securetty is but it sounds like
a vga console thing and thus somewhere between "low priority" and
"historical relic".
Post by Elie De Brauwer
Btw, it contains several functions which are candidates for reuse for
other tools which relate to user management. These functions will be put
common once the need for that becomes clear.
Cool.
Post by Elie De Brauwer
I've just tested this on my system without much special things present,
so there's some room for testing on more 'special' cases.
My aboriginal linux systems boot to a shell prompt and thus don't use
login, I haven't got a test case set up for this.
Post by Elie De Brauwer
Comments welcome.
Tonight my sadly insufficient brainpower is <strike>focused</strike>
waved vaguely towards upgrading "ls", and since I still have this darn
cold that's not much. But this is on the to-review heap. (Currently the
top of that heap is "finish going through the mode parsing stuff", I got
it about 1/3 reviewed I think. Then Georgi's "please send me one
patch... that's 10 patches." pile.)

Thanks,

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Elie De Brauwer
2012-04-28 12:42:47 UTC
Permalink
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).
"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.

my 2 cents
E.
--
Elie De Brauwer
Rob Landley
2012-04-28 20:30:05 UTC
Permalink
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:

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.
David Seikel
2012-04-28 22:27:32 UTC
Permalink
Post by Rob Landley
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?)
I wrote a sysv init (and friends) long ago that might fit into toybox.
I might blow the dust off it and see what happens. It was a clean room
version aiming to be LSB compliant, and working from the LSB specs.

Also wrote it in about 2005. lol
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120429/dd55ac98/attachment.pgp>
Rob Landley
2012-04-29 16:36:41 UTC
Permalink
Post by David Seikel
Post by Rob Landley
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?)
I wrote a sysv init (and friends) long ago that might fit into toybox.
I might blow the dust off it and see what happens. It was a clean room
version aiming to be LSB compliant, and working from the LSB specs.
The LSB actually specifies something useful? I'd written it off as Red
Hat's attempt to shoehorn RPM into debian-based systems...

I'm pretty sure Android _doesn't_ follow anything in it, correct?

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Rob Landley
2012-04-29 17:42:03 UTC
Permalink
Post by David Seikel
I wrote a sysv init (and friends) long ago that might fit into toybox.
I might blow the dust off it and see what happens. It was a clean room
version aiming to be LSB compliant, and working from the LSB specs.
Digging up a copy of this thing turns out to be nontrivial, the original
linuxbase.org page (still the second google hit, after wikipedia) got
Borged by the Linux Foundation and now redirects to a page with NO
DOWNLOAD LINKS. Luckily the sixth google hit is some third party cache
of the actual PDF of section 1, which seems to be the useful bit. (No, I
don't care about x86 vs x86-64 here.)

It's 649 pages long. Why is it 649 pages long? And... Oh wow:

Section 18.1: Mandatory Optional Behaviors.

This entire file is a joke, right?

Ok, page 500 is the start of a 2 page table listing commands... ah I
see, all the [1] ones are posix and the [2] ones are locally tainted...

Ah, there's a web version:

http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/cmdbehav.html

ar at awk batch bc chfn chsh col cpio crontab df dmesg du echo egrep
fgrep file fuser gettext grep groupadd groupdel groupmod groups
gunzip gzip hostname install install_initd ipcrm ipcs killall lpr ls
lsb_release m4 md5sum mknod mktemp more mount msgfmt newgrp od passwd
patch pidof remove_initd renice sed sendmail seq sh shutdown su sync
tar umount useradd userdel usermod xargs zcat

So some of that is new commands (for a definition of "new" that dates
back to the 1970's in the case of stuff like mount), and a bunch of it's
in posix. So what does a delta against a posix command look like? Quick
glance at xargs: it's yanking three command line arguments posix
supports and saying using them is undefined behavior. I.E. this is an
accomodation for a defect in some gnu/dammit package.

Let's look at "more"... yup, again: util-linux hasn't caught up with
current POSIX so we COME OUT WITH A STANDARD SAYING EXPLICITLY WHERE
IT'S OK TO CONFORM TO THE OLDER BEHAVIOR. Why not just say it's ok to
conform to the older behavior? What is WRONG with these people?

This entire standard is a series of workarounds. What a pile of...

And I gotta triage this. (ar and m4 are build tools, lpr isn't really
our problem because these days printers need drivers and that means some
crawling horror like cups...)

Ok, todo item. Thanks for the heads up.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Rob Landley
2012-04-29 16:36:41 UTC
Permalink
Post by David Seikel
Post by Rob Landley
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?)
I wrote a sysv init (and friends) long ago that might fit into toybox.
I might blow the dust off it and see what happens. It was a clean room
version aiming to be LSB compliant, and working from the LSB specs.
The LSB actually specifies something useful? I'd written it off as Red
Hat's attempt to shoehorn RPM into debian-based systems...

I'm pretty sure Android _doesn't_ follow anything in it, correct?

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Rob Landley
2012-04-29 17:42:03 UTC
Permalink
Post by David Seikel
I wrote a sysv init (and friends) long ago that might fit into toybox.
I might blow the dust off it and see what happens. It was a clean room
version aiming to be LSB compliant, and working from the LSB specs.
Digging up a copy of this thing turns out to be nontrivial, the original
linuxbase.org page (still the second google hit, after wikipedia) got
Borged by the Linux Foundation and now redirects to a page with NO
DOWNLOAD LINKS. Luckily the sixth google hit is some third party cache
of the actual PDF of section 1, which seems to be the useful bit. (No, I
don't care about x86 vs x86-64 here.)

It's 649 pages long. Why is it 649 pages long? And... Oh wow:

Section 18.1: Mandatory Optional Behaviors.

This entire file is a joke, right?

Ok, page 500 is the start of a 2 page table listing commands... ah I
see, all the [1] ones are posix and the [2] ones are locally tainted...

Ah, there's a web version:

http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/cmdbehav.html

ar at awk batch bc chfn chsh col cpio crontab df dmesg du echo egrep
fgrep file fuser gettext grep groupadd groupdel groupmod groups
gunzip gzip hostname install install_initd ipcrm ipcs killall lpr ls
lsb_release m4 md5sum mknod mktemp more mount msgfmt newgrp od passwd
patch pidof remove_initd renice sed sendmail seq sh shutdown su sync
tar umount useradd userdel usermod xargs zcat

So some of that is new commands (for a definition of "new" that dates
back to the 1970's in the case of stuff like mount), and a bunch of it's
in posix. So what does a delta against a posix command look like? Quick
glance at xargs: it's yanking three command line arguments posix
supports and saying using them is undefined behavior. I.E. this is an
accomodation for a defect in some gnu/dammit package.

Let's look at "more"... yup, again: util-linux hasn't caught up with
current POSIX so we COME OUT WITH A STANDARD SAYING EXPLICITLY WHERE
IT'S OK TO CONFORM TO THE OLDER BEHAVIOR. Why not just say it's ok to
conform to the older behavior? What is WRONG with these people?

This entire standard is a series of workarounds. What a pile of...

And I gotta triage this. (ar and m4 are build tools, lpr isn't really
our problem because these days printers need drivers and that means some
crawling horror like cups...)

Ok, todo item. Thanks for the heads up.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-04-28 22:27:32 UTC
Permalink
Post by Rob Landley
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?)
I wrote a sysv init (and friends) long ago that might fit into toybox.
I might blow the dust off it and see what happens. It was a clean room
version aiming to be LSB compliant, and working from the LSB specs.

Also wrote it in about 2005. lol
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120429/dd55ac98/attachment-0002.pgp>
Rob Landley
2012-04-28 20:30:05 UTC
Permalink
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:

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.
Elie De Brauwer
2012-04-28 13:35:11 UTC
Permalink
Post by Rob Landley
Specifically, you add three new headers, one of which is in susv4
(syslog.h) and two of which aren't (crypt.h and shadow.h).
This implies we should have another config time probe in
scripts/genconfig.sh to go with the unshare() probe, setting some kind
of symbol (TOYBOX_CSHADOW) that login can depend on the way unshare does
now. We can do one probe for both crypt and shadow, I'm not sure making
shadow configurable in 2012 buys us much. World readable /etc/passwd is
obsolete.
Probably also good to make the new --as-needed stanza be conditionally
added to some sort of $AS_NEEDED evironment variable, and used through
that on the compiler command line. (I dunno what the compiler does on
systems that haven't got -lcrypt, I thin even with --as-needed that's a
build break if the library isn't found. I know glibc and uClibc can
provide this, not sure about musl, who knows about macosx and I still
haven't got a bionic test environment set up. So yeah, not in susv4 or
implies a probe when it comes to headers.)
Attached is a patch which make login depend on probing crypt.h and
shadow.h following the unshare example. I turned these into two probes,
just to keep things a bit more understandable, and i suspect that some
future toys might depend on either shadow or crypt.

Regarding the --as-needed. I can update make.sh to contain something as
-Wl,--as-needed,${REQUIRED_LIBS},--no-as-needed but what would be a
sensible way to populate the $REQUIRED_LIBS variable ? I think that a
toy should actually be able to tell whether or not it requires linking
with a certain library or not, but I don't know/think anything like that
is already foreseen/in place ?

my 2 cents
E.
--
Elie De Brauwer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: login_probe.patch
Type: text/x-patch
Size: 2215 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120428/c774c02c/attachment.bin>
Rob Landley
2012-04-29 01:13:12 UTC
Permalink
Post by Elie De Brauwer
Post by Rob Landley
Specifically, you add three new headers, one of which is in susv4
(syslog.h) and two of which aren't (crypt.h and shadow.h).
This implies we should have another config time probe in
scripts/genconfig.sh to go with the unshare() probe, setting some kind
of symbol (TOYBOX_CSHADOW) that login can depend on the way unshare does
now. We can do one probe for both crypt and shadow, I'm not sure making
shadow configurable in 2012 buys us much. World readable /etc/passwd is
obsolete.
Probably also good to make the new --as-needed stanza be conditionally
added to some sort of $AS_NEEDED evironment variable, and used through
that on the compiler command line. (I dunno what the compiler does on
systems that haven't got -lcrypt, I thin even with --as-needed that's a
build break if the library isn't found. I know glibc and uClibc can
provide this, not sure about musl, who knows about macosx and I still
haven't got a bionic test environment set up. So yeah, not in susv4 or
implies a probe when it comes to headers.)
Attached is a patch which make login depend on probing crypt.h and
shadow.h following the unshare example. I turned these into two probes,
just to keep things a bit more understandable, and i suspect that some
future toys might depend on either shadow or crypt.
Um, can we wait to split them until something _does_ need them split? I
hate having infrastructure awaiting a user, it tends to accumulate and
then not fit right if somebody _does_ need it. (Yes, I have seen code
_preemptively_ bit-rot.)
Post by Elie De Brauwer
Regarding the --as-needed. I can update make.sh to contain something as
-Wl,--as-needed,${REQUIRED_LIBS},--no-as-needed but what would be a
sensible way to populate the $REQUIRED_LIBS variable ?
Have each test do:

REQUIRED_LIBS="$REQUIRED_LIBS,fruitbasket"

And then at the end:

[ ! -z "$REQUIRED_LIBS" ] &&
REQUIRED_LIBS="-Wl,--as-needed$REQUIRED_LIBS,--no-as-needed"

(Note the missing comma before $REQUIRED_LIBS since each addition starts
with one.)
Post by Elie De Brauwer
I think that a
toy should actually be able to tell whether or not it requires linking
with a certain library or not, but I don't know/think anything like that
is already foreseen/in place ?
In theory, yes. In practice, this means manually maintaining
dependencies, which just invites them to be subtly broken in some
combination we never tested. Since the compiler and linker have already
_grown_ this support, we might as well have the dependencies determined
automatically because that shouldn't break (and if it does it should get
fixed upstream).

Note that this also applies to the contents of lib/lib.c. Instead of
working out what to include and what not to include there, I just have
this in configure:

[ -z "$OPTIMIZE" ] &&
OPTIMIZE="-Os -ffunction-sections -fdata-sections -Wl,--gc-sections"

It puts every function and piece of data in its own elf section, and
then garbage collects unused sections.

(Denys Vlasenko did a marvelous presentation at CELF 2010 about why this
breaks glibc's stdio flushing. I can link to the video if you're curious.)
Post by Elie De Brauwer
my 2 cents
E.
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Elie De Brauwer
2012-04-30 06:34:40 UTC
Permalink
Post by Elie De Brauwer
Attached is a patch which make login depend on probing crypt.h and
shadow.h following the unshare example. ?I turned these into two probes,
just to keep things a bit more understandable, and i suspect that some
future toys might depend on either shadow or crypt.
Um, can we wait to split them until something _does_ need them split? ?I
hate having infrastructure awaiting a user, it tends to accumulate and
then not fit right if somebody _does_ need it. (Yes, I have seen code
_preemptively_ bit-rot.)
Fair point, I'll modify my patch to include you comments and post an
update, thanks.
Post by Elie De Brauwer
Regarding the --as-needed. I can update make.sh to contain something as
?-Wl,--as-needed,${REQUIRED_LIBS},--no-as-needed but what would be a
sensible way to populate the $REQUIRED_LIBS variable ?
?REQUIRED_LIBS="$REQUIRED_LIBS,fruitbasket"
?[ ! -z "$REQUIRED_LIBS" ] &&
? ?REQUIRED_LIBS="-Wl,--as-needed$REQUIRED_LIBS,--no-as-needed"
(Note the missing comma before $REQUIRED_LIBS since each addition starts
with one.)
Thanks for the pointer, I'll have this included as well in my patch.
Post by Elie De Brauwer
I think that a
toy should actually be able to tell whether or not it requires linking
with a certain library or not, but I don't know/think anything like that
is already foreseen/in place ?
In theory, yes. ?In practice, this means manually maintaining
dependencies, which just invites them to be subtly broken in some
combination we never tested. Since the compiler and linker have already
_grown_ this support, we might as well have the dependencies determined
automatically because that shouldn't break (and if it does it should get
fixed upstream).
Which is exactly the reason why I asked if something was in place
already, rolling your can always occur, and as a result hitting the
same wall others have hit before your is included for free.
Note that this also applies to the contents of lib/lib.c. Instead of
working out what to include and what not to include there, I just have
[ -z "$OPTIMIZE" ] &&
?OPTIMIZE="-Os -ffunction-sections -fdata-sections -Wl,--gc-sections"
It puts every function and piece of data in its own elf section, and
then garbage collects unused sections.
This as opposed to let's say busybox where every shared function, or
set of a handful of vaguely related functions are stuffed in their own
.c/.h combo. But I agree it's the linkers' job to do linking, I do not
doubt it can do a better job than myself when it comes to linking,
let's make use of it.
(Denys Vlasenko did a marvelous presentation at CELF 2010 about why this
breaks glibc's stdio flushing. I can link to the video if you're curious.)
Links always welcomed, it's only time which is the scarce resource :).
--
Elie De Brauwer
Rob Landley
2012-04-30 16:20:29 UTC
Permalink
Post by Elie De Brauwer
Post by Rob Landley
Post by Elie De Brauwer
I think that a
toy should actually be able to tell whether or not it requires linking
with a certain library or not, but I don't know/think anything like that
is already foreseen/in place ?
In theory, yes. In practice, this means manually maintaining
dependencies, which just invites them to be subtly broken in some
combination we never tested. Since the compiler and linker have already
_grown_ this support, we might as well have the dependencies determined
automatically because that shouldn't break (and if it does it should get
fixed upstream).
Which is exactly the reason why I asked if something was in place
already, rolling your can always occur, and as a result hitting the
same wall others have hit before your is included for free.
I remember (back on busybox) a case where "whether or not you needed
-lm" varied between uClibc and glibc. Whole lotta not wanting to go there...
Post by Elie De Brauwer
Post by Rob Landley
Note that this also applies to the contents of lib/lib.c. Instead of
working out what to include and what not to include there, I just have
[ -z "$OPTIMIZE" ] &&
OPTIMIZE="-Os -ffunction-sections -fdata-sections -Wl,--gc-sections"
It puts every function and piece of data in its own elf section, and
then garbage collects unused sections.
This as opposed to let's say busybox where every shared function, or
set of a handful of vaguely related functions are stuffed in their own
.c/.h combo.
In their defense, they predate linkers growing support for this. And
they hit bugs in it that the glibc/binutils guys still point fingers at
each other about. (Denys explains in the video.)
Post by Elie De Brauwer
But I agree it's the linkers' job to do linking, I do not
doubt it can do a better job than myself when it comes to linking,
let's make use of it.
Post by Rob Landley
(Denys Vlasenko did a marvelous presentation at CELF 2010 about why this
breaks glibc's stdio flushing. I can link to the video if you're curious.)
Links always welcomed, it's only time which is the scarce resource :).
I wasn't online when I wrote that or I would have. :)

Index of that year's videos:
http://free-electrons.com/blog/elc-2010-videos/

Slides and video of talk in question:
http://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf
http://free-electrons.com/pub/video/2010/elc/elc2010-vlasenko-dead-code.ogv

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Rob Landley
2012-04-30 16:20:29 UTC
Permalink
Post by Elie De Brauwer
Post by Rob Landley
Post by Elie De Brauwer
I think that a
toy should actually be able to tell whether or not it requires linking
with a certain library or not, but I don't know/think anything like that
is already foreseen/in place ?
In theory, yes. In practice, this means manually maintaining
dependencies, which just invites them to be subtly broken in some
combination we never tested. Since the compiler and linker have already
_grown_ this support, we might as well have the dependencies determined
automatically because that shouldn't break (and if it does it should get
fixed upstream).
Which is exactly the reason why I asked if something was in place
already, rolling your can always occur, and as a result hitting the
same wall others have hit before your is included for free.
I remember (back on busybox) a case where "whether or not you needed
-lm" varied between uClibc and glibc. Whole lotta not wanting to go there...
Post by Elie De Brauwer
Post by Rob Landley
Note that this also applies to the contents of lib/lib.c. Instead of
working out what to include and what not to include there, I just have
[ -z "$OPTIMIZE" ] &&
OPTIMIZE="-Os -ffunction-sections -fdata-sections -Wl,--gc-sections"
It puts every function and piece of data in its own elf section, and
then garbage collects unused sections.
This as opposed to let's say busybox where every shared function, or
set of a handful of vaguely related functions are stuffed in their own
.c/.h combo.
In their defense, they predate linkers growing support for this. And
they hit bugs in it that the glibc/binutils guys still point fingers at
each other about. (Denys explains in the video.)
Post by Elie De Brauwer
But I agree it's the linkers' job to do linking, I do not
doubt it can do a better job than myself when it comes to linking,
let's make use of it.
Post by Rob Landley
(Denys Vlasenko did a marvelous presentation at CELF 2010 about why this
breaks glibc's stdio flushing. I can link to the video if you're curious.)
Links always welcomed, it's only time which is the scarce resource :).
I wasn't online when I wrote that or I would have. :)

Index of that year's videos:
http://free-electrons.com/blog/elc-2010-videos/

Slides and video of talk in question:
http://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf
http://free-electrons.com/pub/video/2010/elc/elc2010-vlasenko-dead-code.ogv

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Elie De Brauwer
2012-04-30 06:34:40 UTC
Permalink
Post by Elie De Brauwer
Attached is a patch which make login depend on probing crypt.h and
shadow.h following the unshare example. ?I turned these into two probes,
just to keep things a bit more understandable, and i suspect that some
future toys might depend on either shadow or crypt.
Um, can we wait to split them until something _does_ need them split? ?I
hate having infrastructure awaiting a user, it tends to accumulate and
then not fit right if somebody _does_ need it. (Yes, I have seen code
_preemptively_ bit-rot.)
Fair point, I'll modify my patch to include you comments and post an
update, thanks.
Post by Elie De Brauwer
Regarding the --as-needed. I can update make.sh to contain something as
?-Wl,--as-needed,${REQUIRED_LIBS},--no-as-needed but what would be a
sensible way to populate the $REQUIRED_LIBS variable ?
?REQUIRED_LIBS="$REQUIRED_LIBS,fruitbasket"
?[ ! -z "$REQUIRED_LIBS" ] &&
? ?REQUIRED_LIBS="-Wl,--as-needed$REQUIRED_LIBS,--no-as-needed"
(Note the missing comma before $REQUIRED_LIBS since each addition starts
with one.)
Thanks for the pointer, I'll have this included as well in my patch.
Post by Elie De Brauwer
I think that a
toy should actually be able to tell whether or not it requires linking
with a certain library or not, but I don't know/think anything like that
is already foreseen/in place ?
In theory, yes. ?In practice, this means manually maintaining
dependencies, which just invites them to be subtly broken in some
combination we never tested. Since the compiler and linker have already
_grown_ this support, we might as well have the dependencies determined
automatically because that shouldn't break (and if it does it should get
fixed upstream).
Which is exactly the reason why I asked if something was in place
already, rolling your can always occur, and as a result hitting the
same wall others have hit before your is included for free.
Note that this also applies to the contents of lib/lib.c. Instead of
working out what to include and what not to include there, I just have
[ -z "$OPTIMIZE" ] &&
?OPTIMIZE="-Os -ffunction-sections -fdata-sections -Wl,--gc-sections"
It puts every function and piece of data in its own elf section, and
then garbage collects unused sections.
This as opposed to let's say busybox where every shared function, or
set of a handful of vaguely related functions are stuffed in their own
.c/.h combo. But I agree it's the linkers' job to do linking, I do not
doubt it can do a better job than myself when it comes to linking,
let's make use of it.
(Denys Vlasenko did a marvelous presentation at CELF 2010 about why this
breaks glibc's stdio flushing. I can link to the video if you're curious.)
Links always welcomed, it's only time which is the scarce resource :).
--
Elie De Brauwer
Elie De Brauwer
2012-05-01 08:20:25 UTC
Permalink
Post by Rob Landley
Post by Elie De Brauwer
Attached is a patch which make login depend on probing crypt.h and
shadow.h following the unshare example. I turned these into two probes,
just to keep things a bit more understandable, and i suspect that some
future toys might depend on either shadow or crypt.
Um, can we wait to split them until something _does_ need them split? I
hate having infrastructure awaiting a user, it tends to accumulate and
then not fit right if somebody _does_ need it. (Yes, I have seen code
_preemptively_ bit-rot.)
Post by Elie De Brauwer
Regarding the --as-needed. I can update make.sh to contain something as
-Wl,--as-needed,${REQUIRED_LIBS},--no-as-needed but what would be a
sensible way to populate the $REQUIRED_LIBS variable ?
REQUIRED_LIBS="$REQUIRED_LIBS,fruitbasket"
[ ! -z "$REQUIRED_LIBS" ]&&
REQUIRED_LIBS="-Wl,--as-needed$REQUIRED_LIBS,--no-as-needed"
(Note the missing comma before $REQUIRED_LIBS since each addition starts
with one.)
Modified, see patch in attach. I put the required variable in a separate
generated file, which gets sourced/cleaned by the main make.

The patch also includes the detection of crpyt.h and shadow.h but now
combined into a single variable.

For now -lutil still lives as it was before, I haven't got a clue
whether this needs to be aligned or whether it's always there (nor what
might depend on it, but if somebody can give me a pointer I can also
align this).

my 2 cents
E.
--
Elie De Brauwer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: login_probe.patch
Type: text/x-patch
Size: 3974 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120501/773655a8/attachment.bin>
Rob Landley
2012-05-14 23:38:20 UTC
Permalink
Post by Elie De Brauwer
Post by Rob Landley
Post by Elie De Brauwer
Attached is a patch which make login depend on probing crypt.h and
shadow.h following the unshare example. I turned these into two probes,
just to keep things a bit more understandable, and i suspect that some
future toys might depend on either shadow or crypt.
Um, can we wait to split them until something _does_ need them split? I
hate having infrastructure awaiting a user, it tends to accumulate and
then not fit right if somebody _does_ need it. (Yes, I have seen code
_preemptively_ bit-rot.)
Post by Elie De Brauwer
Regarding the --as-needed. I can update make.sh to contain something as
-Wl,--as-needed,${REQUIRED_LIBS},--no-as-needed but what would be a
sensible way to populate the $REQUIRED_LIBS variable ?
REQUIRED_LIBS="$REQUIRED_LIBS,fruitbasket"
[ ! -z "$REQUIRED_LIBS" ]&&
REQUIRED_LIBS="-Wl,--as-needed$REQUIRED_LIBS,--no-as-needed"
(Note the missing comma before $REQUIRED_LIBS since each addition starts
with one.)
Modified, see patch in attach. I put the required variable in a separate
generated file, which gets sourced/cleaned by the main make.
Sorry for the delay responding.

Unfortunately, I don't really like this version either: it seems like it
really shouldn't need a "generated" file for command line arguments.
(This file is not a naturally included chunk the way headers and kconfig
chunks are...)

After rejecting a patch twice I feel obligated to fix it myself, which I
haven't had a chance to do yet, hence the delay...

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Rob Landley
2012-05-23 17:52:30 UTC
Permalink
Post by Rob Landley
Sorry for the delay responding.
Unfortunately, I don't really like this version either: it seems like it
really shouldn't need a "generated" file for command line arguments.
(This file is not a naturally included chunk the way headers and kconfig
chunks are...)
After rejecting a patch twice I feel obligated to fix it myself, which I
haven't had a chance to do yet, hence the delay...
No problem, we all know you've been quite occupied. I'll gladly take
another go at it and do some typing, but perhaps it's best to first
figure out the approach you will like. The generated file was a way to
circumvent running the probes all over again.
Understood. However, if what we're testing is just "does our build
environment have this library", and if so always throwing it into the
--as-needed pile and letting the linker figure out whether or not it's
actually used, then doing so at compile time shouldn't be a huge deal.
(Compiling "true with -libm shouldn't take very long.)

We're not really testing that the libcrypt they have _works_ (that would
be setting a config symbol and dropping out the commands). We're just
trying to avoid the build break from an unknown library:

$ echo "int main(int a, char **b) {return 0;}" | \
gcc -xc -o /dev/null -Wl,--as-needed -lm -lcrypt -lwalrus
/usr/bin/ld: cannot find -lwalrus
collect2: ld returned 1 exit status

We can probably assume that if libcrypt is there it provides some
minimal functionality. Seems straightforward enough, I can test it and
check it in this evening.

Rob

P.S. after spending this morning once again lifting heavy boxes, I've
finally got everything out of the condo. I am _moved_. Cleaning people
come this afternoon and realtor starts showing it to people tomorrow.
The reason this is relevant is I get some of my evening and weekend time
back again. Yay!
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Rob Landley
2012-05-23 17:52:30 UTC
Permalink
Post by Rob Landley
Sorry for the delay responding.
Unfortunately, I don't really like this version either: it seems like it
really shouldn't need a "generated" file for command line arguments.
(This file is not a naturally included chunk the way headers and kconfig
chunks are...)
After rejecting a patch twice I feel obligated to fix it myself, which I
haven't had a chance to do yet, hence the delay...
No problem, we all know you've been quite occupied. I'll gladly take
another go at it and do some typing, but perhaps it's best to first
figure out the approach you will like. The generated file was a way to
circumvent running the probes all over again.
Understood. However, if what we're testing is just "does our build
environment have this library", and if so always throwing it into the
--as-needed pile and letting the linker figure out whether or not it's
actually used, then doing so at compile time shouldn't be a huge deal.
(Compiling "true with -libm shouldn't take very long.)

We're not really testing that the libcrypt they have _works_ (that would
be setting a config symbol and dropping out the commands). We're just
trying to avoid the build break from an unknown library:

$ echo "int main(int a, char **b) {return 0;}" | \
gcc -xc -o /dev/null -Wl,--as-needed -lm -lcrypt -lwalrus
/usr/bin/ld: cannot find -lwalrus
collect2: ld returned 1 exit status

We can probably assume that if libcrypt is there it provides some
minimal functionality. Seems straightforward enough, I can test it and
check it in this evening.

Rob

P.S. after spending this morning once again lifting heavy boxes, I've
finally got everything out of the condo. I am _moved_. Cleaning people
come this afternoon and realtor starts showing it to people tomorrow.
The reason this is relevant is I get some of my evening and weekend time
back again. Yay!
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Rob Landley
2012-05-14 23:38:20 UTC
Permalink
Post by Elie De Brauwer
Post by Rob Landley
Post by Elie De Brauwer
Attached is a patch which make login depend on probing crypt.h and
shadow.h following the unshare example. I turned these into two probes,
just to keep things a bit more understandable, and i suspect that some
future toys might depend on either shadow or crypt.
Um, can we wait to split them until something _does_ need them split? I
hate having infrastructure awaiting a user, it tends to accumulate and
then not fit right if somebody _does_ need it. (Yes, I have seen code
_preemptively_ bit-rot.)
Post by Elie De Brauwer
Regarding the --as-needed. I can update make.sh to contain something as
-Wl,--as-needed,${REQUIRED_LIBS},--no-as-needed but what would be a
sensible way to populate the $REQUIRED_LIBS variable ?
REQUIRED_LIBS="$REQUIRED_LIBS,fruitbasket"
[ ! -z "$REQUIRED_LIBS" ]&&
REQUIRED_LIBS="-Wl,--as-needed$REQUIRED_LIBS,--no-as-needed"
(Note the missing comma before $REQUIRED_LIBS since each addition starts
with one.)
Modified, see patch in attach. I put the required variable in a separate
generated file, which gets sourced/cleaned by the main make.
Sorry for the delay responding.

Unfortunately, I don't really like this version either: it seems like it
really shouldn't need a "generated" file for command line arguments.
(This file is not a naturally included chunk the way headers and kconfig
chunks are...)

After rejecting a patch twice I feel obligated to fix it myself, which I
haven't had a chance to do yet, hence the delay...

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Elie De Brauwer
2012-05-01 08:20:25 UTC
Permalink
Post by Rob Landley
Post by Elie De Brauwer
Attached is a patch which make login depend on probing crypt.h and
shadow.h following the unshare example. I turned these into two probes,
just to keep things a bit more understandable, and i suspect that some
future toys might depend on either shadow or crypt.
Um, can we wait to split them until something _does_ need them split? I
hate having infrastructure awaiting a user, it tends to accumulate and
then not fit right if somebody _does_ need it. (Yes, I have seen code
_preemptively_ bit-rot.)
Post by Elie De Brauwer
Regarding the --as-needed. I can update make.sh to contain something as
-Wl,--as-needed,${REQUIRED_LIBS},--no-as-needed but what would be a
sensible way to populate the $REQUIRED_LIBS variable ?
REQUIRED_LIBS="$REQUIRED_LIBS,fruitbasket"
[ ! -z "$REQUIRED_LIBS" ]&&
REQUIRED_LIBS="-Wl,--as-needed$REQUIRED_LIBS,--no-as-needed"
(Note the missing comma before $REQUIRED_LIBS since each addition starts
with one.)
Modified, see patch in attach. I put the required variable in a separate
generated file, which gets sourced/cleaned by the main make.

The patch also includes the detection of crpyt.h and shadow.h but now
combined into a single variable.

For now -lutil still lives as it was before, I haven't got a clue
whether this needs to be aligned or whether it's always there (nor what
might depend on it, but if somebody can give me a pointer I can also
align this).

my 2 cents
E.
--
Elie De Brauwer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: login_probe.patch
Type: text/x-patch
Size: 3974 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120501/773655a8/attachment-0002.bin>
Rob Landley
2012-04-29 01:13:12 UTC
Permalink
Post by Elie De Brauwer
Post by Rob Landley
Specifically, you add three new headers, one of which is in susv4
(syslog.h) and two of which aren't (crypt.h and shadow.h).
This implies we should have another config time probe in
scripts/genconfig.sh to go with the unshare() probe, setting some kind
of symbol (TOYBOX_CSHADOW) that login can depend on the way unshare does
now. We can do one probe for both crypt and shadow, I'm not sure making
shadow configurable in 2012 buys us much. World readable /etc/passwd is
obsolete.
Probably also good to make the new --as-needed stanza be conditionally
added to some sort of $AS_NEEDED evironment variable, and used through
that on the compiler command line. (I dunno what the compiler does on
systems that haven't got -lcrypt, I thin even with --as-needed that's a
build break if the library isn't found. I know glibc and uClibc can
provide this, not sure about musl, who knows about macosx and I still
haven't got a bionic test environment set up. So yeah, not in susv4 or
implies a probe when it comes to headers.)
Attached is a patch which make login depend on probing crypt.h and
shadow.h following the unshare example. I turned these into two probes,
just to keep things a bit more understandable, and i suspect that some
future toys might depend on either shadow or crypt.
Um, can we wait to split them until something _does_ need them split? I
hate having infrastructure awaiting a user, it tends to accumulate and
then not fit right if somebody _does_ need it. (Yes, I have seen code
_preemptively_ bit-rot.)
Post by Elie De Brauwer
Regarding the --as-needed. I can update make.sh to contain something as
-Wl,--as-needed,${REQUIRED_LIBS},--no-as-needed but what would be a
sensible way to populate the $REQUIRED_LIBS variable ?
Have each test do:

REQUIRED_LIBS="$REQUIRED_LIBS,fruitbasket"

And then at the end:

[ ! -z "$REQUIRED_LIBS" ] &&
REQUIRED_LIBS="-Wl,--as-needed$REQUIRED_LIBS,--no-as-needed"

(Note the missing comma before $REQUIRED_LIBS since each addition starts
with one.)
Post by Elie De Brauwer
I think that a
toy should actually be able to tell whether or not it requires linking
with a certain library or not, but I don't know/think anything like that
is already foreseen/in place ?
In theory, yes. In practice, this means manually maintaining
dependencies, which just invites them to be subtly broken in some
combination we never tested. Since the compiler and linker have already
_grown_ this support, we might as well have the dependencies determined
automatically because that shouldn't break (and if it does it should get
fixed upstream).

Note that this also applies to the contents of lib/lib.c. Instead of
working out what to include and what not to include there, I just have
this in configure:

[ -z "$OPTIMIZE" ] &&
OPTIMIZE="-Os -ffunction-sections -fdata-sections -Wl,--gc-sections"

It puts every function and piece of data in its own elf section, and
then garbage collects unused sections.

(Denys Vlasenko did a marvelous presentation at CELF 2010 about why this
breaks glibc's stdio flushing. I can link to the video if you're curious.)
Post by Elie De Brauwer
my 2 cents
E.
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Elie De Brauwer
2012-04-28 12:42:47 UTC
Permalink
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).
"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.

my 2 cents
E.
--
Elie De Brauwer
Elie De Brauwer
2012-04-28 13:35:11 UTC
Permalink
Post by Rob Landley
Specifically, you add three new headers, one of which is in susv4
(syslog.h) and two of which aren't (crypt.h and shadow.h).
This implies we should have another config time probe in
scripts/genconfig.sh to go with the unshare() probe, setting some kind
of symbol (TOYBOX_CSHADOW) that login can depend on the way unshare does
now. We can do one probe for both crypt and shadow, I'm not sure making
shadow configurable in 2012 buys us much. World readable /etc/passwd is
obsolete.
Probably also good to make the new --as-needed stanza be conditionally
added to some sort of $AS_NEEDED evironment variable, and used through
that on the compiler command line. (I dunno what the compiler does on
systems that haven't got -lcrypt, I thin even with --as-needed that's a
build break if the library isn't found. I know glibc and uClibc can
provide this, not sure about musl, who knows about macosx and I still
haven't got a bionic test environment set up. So yeah, not in susv4 or
implies a probe when it comes to headers.)
Attached is a patch which make login depend on probing crypt.h and
shadow.h following the unshare example. I turned these into two probes,
just to keep things a bit more understandable, and i suspect that some
future toys might depend on either shadow or crypt.

Regarding the --as-needed. I can update make.sh to contain something as
-Wl,--as-needed,${REQUIRED_LIBS},--no-as-needed but what would be a
sensible way to populate the $REQUIRED_LIBS variable ? I think that a
toy should actually be able to tell whether or not it requires linking
with a certain library or not, but I don't know/think anything like that
is already foreseen/in place ?

my 2 cents
E.
--
Elie De Brauwer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: login_probe.patch
Type: text/x-patch
Size: 2215 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120428/c774c02c/attachment-0002.bin>
Elie De Brauwer
2012-04-24 21:16:07 UTC
Permalink
Hello world,

In attachment you can find an initial version of login. For the moment
still rather basic, it supports:
- shadow passwords
- /etc/nologon
- /etc/motd
- passwd style account locking
It requires linking with glibc's crypt (for crypt()) for now.

It does not support pam/securetty/ etc/issue / selinux/utmp yet.
Btw, it contains several functions which are candidates for reuse for
other tools which relate to user management. These functions will be put
common once the need for that becomes clear.

I've just tested this on my system without much special things present,
so there's some room for testing on more 'special' cases.

Comments welcome.

my 2 cents
E.
--
Elie De Brauwer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: login.patch
Type: text/x-patch
Size: 8211 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120424/506d6887/attachment-0002.bin>
Rob Landley
2012-04-25 02:18:38 UTC
Permalink
Post by Elie De Brauwer
Hello world,
In attachment you can find an initial version of login. For the moment
- shadow passwords
- /etc/nologon
- /etc/motd
- passwd style account locking
It requires linking with glibc's crypt (for crypt()) for now.
Applied, but with reservations.

Specifically, you add three new headers, one of which is in susv4
(syslog.h) and two of which aren't (crypt.h and shadow.h).

This implies we should have another config time probe in
scripts/genconfig.sh to go with the unshare() probe, setting some kind
of symbol (TOYBOX_CSHADOW) that login can depend on the way unshare does
now. We can do one probe for both crypt and shadow, I'm not sure making
shadow configurable in 2012 buys us much. World readable /etc/passwd is
obsolete.

Probably also good to make the new --as-needed stanza be conditionally
added to some sort of $AS_NEEDED evironment variable, and used through
that on the compiler command line. (I dunno what the compiler does on
systems that haven't got -lcrypt, I thin even with --as-needed that's a
build break if the library isn't found. I know glibc and uClibc can
provide this, not sure about musl, who knows about macosx and I still
haven't got a bionic test environment set up. So yeah, not in susv4 or
implies a probe when it comes to headers.)
Post by Elie De Brauwer
It does not support pam/securetty/ etc/issue / selinux/utmp yet.
Not hugely bothered by the lack of any of that. I vaguely recall pam
support is mostly libc's problem, and selinux is _entirely_ Red Hat's
problem

(<rant type="selinux">If you want to run PHEL (Pointy Hair Enterprise
Linux), you know where to find it. I can be talked out of this position,
but am waiting for actual users to show up before caring. Making the
system more COMPLICATED is not the same as making it more SECURE. Secure
works like waterproof. Clueless bureaucrats tend to confuse availability
with security: clustering with heartbeat and failover may keep the
system up through lightning strikes but doesn't keep the right data in
and the wrong data out. Geographic distribution makes security _harder_,
but it _does_ increase the price tag, which makes the pointy-haired
happy in a "something must be done, this is something, therefore it must
be done" way. </rant>)

Isn't /etc/issue your shell profile's problem (or is that motd)?

I note that multi-user shared server systems aren't really the common
case anymore. (When that _does_ happen it generally involves a vm or
containers these days.) The real advantage of a multi-user OS these days
is your programs can have roles so your web browser can't format your
hard drive without a password. That's valuable, but doesn't involve
friendly little notes from the sysadmin. If you've got one, they can
email you.

As for utmp, that might be implicitly required by susv4, but a quick
glance isn't finding it. ("who" is querying pty/tty, not login
records.) I don't actually remember what securetty is but it sounds like
a vga console thing and thus somewhere between "low priority" and
"historical relic".
Post by Elie De Brauwer
Btw, it contains several functions which are candidates for reuse for
other tools which relate to user management. These functions will be put
common once the need for that becomes clear.
Cool.
Post by Elie De Brauwer
I've just tested this on my system without much special things present,
so there's some room for testing on more 'special' cases.
My aboriginal linux systems boot to a shell prompt and thus don't use
login, I haven't got a test case set up for this.
Post by Elie De Brauwer
Comments welcome.
Tonight my sadly insufficient brainpower is <strike>focused</strike>
waved vaguely towards upgrading "ls", and since I still have this darn
cold that's not much. But this is on the to-review heap. (Currently the
top of that heap is "finish going through the mode parsing stuff", I got
it about 1/3 reviewed I think. Then Georgi's "please send me one
patch... that's 10 patches." pile.)

Thanks,

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Continue reading on narkive:
Loading...