Corey Hickey wrote:
> I don't know why the malloc() fails. I went to the same line in my
> slmodemd binary that doesn't have 10_drop_privileges.diff, and that
> malloc() succeeded, with the same arguments.
>
> Going back to the regular privilege-dropping binary, I used gdb to run
> some malloc() tests immediately before and immediately after the
> setuid() call. The results showed that malloc() could only allocate a
> small amount of memory after the setuid().
Ok, here's the problem.
modem_main.c:976 function modem_main()
----------------------------------------------------------------------
if (need_realtime) {
struct sched_param prm;
if(mlockall(MCL_CURRENT|MCL_FUTURE)) {
ERR("mlockall: %s\n",strerror(errno));
}
----------------------------------------------------------------------
That chunk of code runs when slmodemd starts up; the modem_start() code
I mentioned in my last email runs when the modem is dialed. So, the
mlockall(MCL_FUTURE) is allowing only a very limited allocation of
memory after the setuid().
Here's a gdb log of me breaking execution right after the above code and
then running setuid() and malloc(); the first malloc(16384) works, but
the next ones fail.
----------------------------------------------------------------------
# gdb modem/slmodemd
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) b modem_main.c:981
Breakpoint 1 at 0x804b748: file modem_main.c, line 981.
(gdb) r -a --debug
Starting program:
/usr/local/src/sl-modem/sl-modem-2.9.11~20080817/modem/slmodemd -a --debug
[Thread debugging using libthread_db enabled]
[New Thread 0xb7cf26b0 (LWP 9688)]
SmartLink Soft Modem: version 2.9.11 Feb 15 2009 15:24:03
<425.285129> SmartLink Soft Modem: version 2.9.11 Feb 15 2009 15:24:03
<425.285334> modem:1: startup modem...
<425.285634> modem:1: update termios...
symbolic link `/dev/ttySL0' -> `/dev/pts/4' created.
modem `modem:1' created. TTY is `/dev/pts/4'
<425.301313> open file: /var/lib/slmodem/data.modem:1...
[Switching to Thread 0xb7cf26b0 (LWP 9688)]
Breakpoint 1, modem_main (dev_name=0x810b0b7 "modem:1") at modem_main.c:981
981 prm.sched_priority = sched_get_priority_max(SCHED_FIFO);
(gdb) print setuid(105)
$1 = 0
(gdb) print malloc(16384)
$2 = 163347000
(gdb)
$3 = 0
(gdb)
$4 = 0
(gdb)
$5 = 0
(gdb)
----------------------------------------------------------------------
Removing the MCL_FUTURE flag makes slmodemd work for me, as far as I can
tell. Remember that I don't have a phone line to test here. It gets past
the modem_start() code, at least, and behaves just like my binary that
has the privilege-dropping patch removed.
I don't know if that's an acceptable solution; locking all allocated
memory into RAM seems useful. Then again, I wouldn't really expect a
currently-running slmodemd process to get swapped out unless memory
constraints are extreme. I don't know the original rationale.
-Corey
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
