Bugzilla Bug 209294

While setting up a machine that requires pppoe I ran into this problem:

I'm using baselayout-2.0.0, openrc-9999 and ppp-2.4.4-r13 from your
(uberlord's) git overlay. If I set username_ppp0 and password_ppp0 then ppp
fails like this:

Jan 29 19:45:19 [pppd] PPP session is 6738
Jan 29 19:45:19 [pppd] Using interface ppp0
Jan 29 19:45:19 [pppd] Connect: ppp0 <--> eth1
Jan 29 19:45:23 [pppd] LCP terminated by peer
Jan 29 19:45:25 [pppd] Terminating on signal 15
Jan 29 19:45:26 [pppd] Connection terminated.
Jan 29 19:45:26 [pppd] Modem hangup
Jan 29 19:45:26 [pppd] Exit. 

I tracked this down to the point that the password is not being 'attached' to
ppp correctly. I commented the password and added pppd_ppp0=( "password xxx"
[...] ). Then ppp started as usual.

This does not happen with current stable baselayout-1 so it's a regression.

$ emerge --info
Portage 2.1.3.19 (uclibc/ppc, gcc-4.1.2, uclibc-0.9.28.3-r2, 2.6.24-efika ppc)
=================================================================
System uname: 2.6.24-efika ppc G2_LE
Timestamp of tree: Sun, 27 Jan 2008 09:00:01 +0000
app-shells/bash:     3.2_p17-r1
dev-lang/python:     2.4.4-r6
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 2.0.0
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.61-r1
sys-devel/automake:  1.10
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.23-r3
ACCEPT_KEYWORDS="ppc"
CBUILD="powerpc-gentoo-linux-uclibc"
CFLAGS="-Os -pipe"
CHOST="powerpc-gentoo-linux-uclibc"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/gentoo-release
/etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-Os -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer nodoc noinfo noman sandbox
sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://192.168.0.2/ http://gentoo.virginmedia.com/"
LDFLAGS="-Wl,-O1"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="bitmap-fonts bzip2 cli cracklib dhcp dri gnutls ipv6 midi mudflap ncurses
openmp pcre ppc readline reflection session spl truetype-fonts type1-fonts
uclibc unicode xorg zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare
dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw
multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias
auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm
authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache
dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache
filter headers include info log_config logio mem_cache mime mime_magic
negotiation rewrite setenvif speling status unique_id userdir usertrack
vhost_alias" ELIBC="uclibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses
text" USERLAND="GNU" VIDEO_CARDS="dummy fbdev v4l"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS


$ cat /etc/conf.d/net 
modules=( "iproute2" )
config_eth0=( "192.168.0.1/24" )
#routes_eth0=( "default via 192.168.0.1" )

config_eth1=( null )

config_ppp0=( "ppp" )
link_ppp0="eth1"
plugins_ppp0=( "pppoe" )
username_ppp0="xxxxxxxxxxxx@alice-dsl.de"
#password_ppp0="xxxxxxxx"
pppd_ppp0=(
        #"noauth"
        "defaultroute"
        "usepeerdns"
        "holdoff 3"
        "child-timeout 60"
        "lcp-echo-interval 15"
        "lcp-echo-failure 3"
        "password xxxxxxxx"
        noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp
)

depend_ppp0() {
        need net.eth1
}

uhm.. uberlord is retired. I'm reassigning to "default assignee of selcted
component".

You can always file openrc specific bugs at
http://bugs.marples.name/enter_bug.cgi?product=OpenRC

Please attach the output of /etc/init.d/net.ppp0 --debug start.
Feel free to mask out the passwords, but leave everthing else intact.

ok. will use your bug tracker next time. I wasn't aware of it.. the package in
your overlay does not have metadata.xml.

Created an attachment (id=142962) [edit]
output of /e/i.d/net.ppp0 --debug start

Well, it looks like openrc is doing the right thing as it's printing the
password to s-s-d on fd0

To verify that is working, we can do this
echo foo | /sbin/start-stop-daemon --start --exec /bin/cat -- /proc/self/fd/0

And if it works, you should see
foo
* start-stop-daemon: /bin/cat died

So it looks like the error is with ppp.

You shouldn't use just echo when sending the password because you must send the
password *without* end-of-line. "echo -n" is the right way to pass the
password.

(In reply to comment #7)
> You shouldn't use just echo when sending the password because you must send the
> password *without* end-of-line. "echo -n" is the right way to pass the
> password.
> 

printf "%s" "${password}"

is what we do and is much more portable, as echo isn't

Well, echo is an internal sh command while printf is not and therefore the
password will be briefly visible to a local user through "ps -ef | grep printf"
command.

(In reply to comment #9)
> Well, echo is an internal sh command while printf is not and therefore the
> password will be briefly visible to a local user through "ps -ef | grep printf"
> command.

printf is a bultin for bash and dash. Surprisingly not for busybox.

So do we have a resolution here guys?

sorry, I haven't been around my DSL connection for some weeks and last week I
just forgot about this bug. Back on topic:

The following two commands succeed:

$ printf "%s" "xxxx" | /usr/sbin/pppd unit 0 user xxxx@alice-dsl.de remotename
ppp0 linkname ppp0 defaultroute usepeerdns holdoff 3 child-timeout 60
lcp-echo-interval 15 lcp-echo-failure 3 noaccomp noccp nobsdcomp nodeflate
nopcomp novj novjccomp plugin passwordfd.so passwordfd 0 defaultmetric 4004
maxfail 0 persist connect true plugin rp-pppoe.so eth1 nodetach

and 

$ printf "%s" "xxxx" | start-stop-daemon --start --exec /usr/sbin/pppd
--pidfile /var/run/ppp-ppp0.pid -- unit 0 user xxxx@alice-dsl.de remotename
ppp0 linkname ppp0 defaultroute usepeerdns holdoff 3 child-timeout 60
lcp-echo-interval 15 lcp-echo-failure 3 noaccomp noccp nobsdcomp nodeflate
nopcomp novj novjccomp plugin passwordfd.so passwordfd 0 defaultmetric 4004
maxfail 0 persist connect true plugin rp-pppoe.so eth1 nodetach

pppd is doing the "right thing", is it? So the error seems to be somewhere in
openrc. I'm also seeing the correct output from comment #6:

# echo foo | /sbin/start-stop-daemon --start --exec /bin/cat -- /proc/self/fd/0
foo
 * start-stop-daemon: /bin/cat died


Do we have success reports about openrc starting pppd? My config might be
wrong?

[ I have neither upgraded to 0.2, which is in portage nor rebuild -9999 since
the initial bug report ]

you can configure whether busybox uses printf as a builtin

vapier: I'm not sure, if you got this right: I'm not using busybox but a
"normal" system. comment #10 was a general statement.

i was merely responding to Roy's analysis of printf/busybox-builtin ... i made
no statement about anything else

Some password problems had been solved for baselayout1 in bug #134337. If the
pppd daemonized, the function detach() in pppd/main.c closed descriptors 0, 1
and 2, so it was not possible to pass passwords via stdin. I've just upgraded
and I have some problems with pppd too (something with updetach), so I will
check it in the evening (CET time).

I confirm the problem here to when upgrading to openrc :

Apr 16 19:09:37 xwing pppd[8861]: Plugin passwordfd.so loaded.
Apr 16 19:09:37 xwing pppd[8861]: Plugin rp-pppoe.so loaded.
Apr 16 19:09:37 xwing pppd[8861]: RP-PPPoE plugin version 3.3 compiled against
pppd 2.4.4
Apr 16 19:09:37 xwing pppd[8862]: pppd 2.4.4 started by root, uid 0
Apr 16 19:09:52 xwing pppd[8862]: PPP session is 10039
Apr 16 19:09:52 xwing pppd[8862]: Using interface ppp0
Apr 16 19:09:52 xwing pppd[8862]: Connect: ppp0 <--> net
Apr 16 19:09:55 xwing pppd[8862]: CHAP authentication failed: Authentication
failed
Apr 16 19:09:55 xwing pppd[8862]: CHAP authentication failed
Apr 16 19:09:55 xwing pppd[8862]: Connection terminated.


An other way to work arround the problem is to add the "updetach" option to
pppd_ppp0.
But it sounds a bit weird since it will hang the boot if ADSL does not goes up
correctly for any reason...

I tried to play with file descriptors for passing password, but without any
success - because the startup script is using /bin/sh, not /bin/bash. So I
cannot say if the problem is somewhere here.

I'm using simple pppd (no pppoe or others) and it works without "updetach".
With "updetach" it fails for the first time and succeeds when pppd tries to
connect for the second time automatically (on the background). But this might
be another story...

Command like this works:

printf "%s" "password" |/usr/sbin/pppd unit 0 user user8@isp.tld remotename
ppp0 linkname ppp0 noipdefault noauth defaultroute usepeerdns mtu 1492
lcp-echo-interval 15 lcp-echo-failure 3 plugin passwordfd.so passwordfd 3
defaultmetric 4006 maxfail 0 persist connect true plugin rp-pppoe.so eth1 3<&0

fd 3 is not closed by pppd when detach.

But the start-stop-daemon(/sbin/rc) closes fd 3..1023 (RLIMIT_NOFILE)

Created an attachment (id=156991) [edit]
add --dont-closefd option to openrc

Created an attachment (id=157049) [edit]
little changes

Not going to fly as you're using bashisms in the script (3<&0).
To work with non bash shells, we kinda have to use fd 0.
In my testing, s-s-d passes this just fine. So if pppd should be patched to
accept fd 0, if indeed it is the bug here.

I can confirm that pppd close stdin/stdout/stderr in certain situations, but I
think passwordfd plugin must be patched, not pppd. That plugin should read and
store the password the moment it gets loaded.

I will create a new ppp revision and ask you guys to test it. In the mean time,
just don't use password_ppp0.

(In reply to comment #23)
> I can confirm that pppd close stdin/stdout/stderr in certain situations, but I
> think passwordfd plugin must be patched, not pppd. That plugin should read and
> store the password the moment it gets loaded.
> 
> I will create a new ppp revision and ask you guys to test it. In the mean time,
> just don't use password_ppp0.
> 

IMHO you should rather  integrate passwdfd plugin into the pppd's source code.
The plug-in architecture design is inconsistent with parsing argumetns in
plug-in.

Or it must read passwd allways from stdin(0), without parsing any option.

Or we can use /etc/ppp/pap-secrets like anybody else.

Created an attachment (id=157809) [edit]
passwordfd-read-early.patch

Guys, please test the attached patch. This will read password from file
descriptor as soon as option parser interprets "passwordfd" string.

Fixed (I hope) in ppp-2.4.4-r16.

None of you seems interested in testing my patch... Nice to see so many users
ready to help you when you're working to fix their problem. :-/