Bug 52029

This defect is considered MUST-FIX for Fairfax.

Can you test uucp-1.06.1-30 - does that work for you?

Can you test uucp-1.06.1-30 - does that work for you?

no. does not work.

I installed uucp-1.06.1-30.i386.rpm & lockdev-1.0.0-13.i386.rpm

when I do the following:

	uucico -S <uucp server name>

I get the following logged to /var/log/uucp/Log

	uucico <svr name> - (2001-08-31 19:21:08.36 24824) ERROR: All matching ports in
use

for some reason, the new uucico thinks that the dial up port is
in use.

I note that the timestamp on the directory /var/lock/uucp/
changes to match the date/time I ussied the uucico command, if
that helps.

-Greg

The timestamp on /var/lock/uucp reflects the creation of
a per-system lock in that directory.

What's in /var/lock? 

Otherwise, please attach the output of
	strace -o /tmp/xxx uucico -S <server>
here, and I'll try to figger what's up. Thanks.

ls -l /var/lock
total 3
drwxr-xr-x    2 root     root         1024 Aug 27 21:38 subsys/
drwxr-xr-x    2 uucp     uucp         1024 Aug 31 20:47 uucp/
drwxrwxrwt    2 root     root         1024 Aug 26 22:50 xemacs/

I am suspecting a permissions problem.
if I

	uucico -S lugs-server


as myself, I get the message

	ERROR: All matching ports in use

in /var/log/uucp/Log

If I su to uucp (after allowing uucp to login), the same
uucico command will work successfully.

If I su to root, also it will work.

is uucico now dropping ths suid perms once it starts ? if yes,
then it will fail to read teh config files. The strace indicates that this is
what is happening...

strace output attached.

Created attachment 30294 [details]
strace output

Yes, all uucp problems are "permission problems" :-)

The strace indicates

open("/var/log/uucp/Log", O_WRONLY|O_APPEND|O_CREAT|O_NOCTTY, 0644) = -1 EACCES
(Permission denied)
write(2, "uucico: /var/log/uucp/Log: can n"..., 68) = 68

as the cause of the failure. That has nothing to do with the device
locking patch applied in uucp-1.06.1-30.

Sanity check: Is uucico functioning correctly if
invoked as root and/or uucp?

There is no "now dropping the suid" change. The only other
patch is to block an exploit in uuxqt.

yes, uucico works as expected if I su root, or su uucp

(which strongly suggests that uucico is dropping privs)

-Greg

uucico dropping privs is a different problem than device locking,
so I'm outta here :-)

We now return you to previously scheduled programming ...

I been debugging this, w/ print statements (suid/sgid progs are such a
pain in the ass to debug w/ a debugger).

I have traced the uucp problems down to the following (which I think belongs to
you, correct me if I am wrong).

in uucico.c, iuport_lock
        fconn_lock() is called to lock the port.

        fconn_lock calls fsserial_lockfile() (for UUCONF_PORTTYPE_MODEM)

I littered some ulog() stmts in fsserial_lockfile() to figure out what's
going on.

the BAUDBOY code is compiled, and the code:

        ttylock(qsysdep->zdevice)

is passed "/dev/cua1", and returns "-13"

I cannot find the code for ttylock(), and I an not sure how to interpret the
"-13" return value.

The perms of /dev/cua1 is:

        crw-rw----    1 root     uucp       5,  65 Aug 31 23:00 /dev/cua1

which is correct.

uucico is sgid uucp, which also seems correct.

any idea what ttylock() is doing ?

/usr/include/baudboy.h has ttylock(), basically an exec of
/usr/sbin/lockdev and remapping status back to an errno.

A return of -13 is a -EACCESS return from an access(2)
check on /dev/cua1. Remember, access(2) uses the
real uid/gid, not the effective uid/gid to perform
it's check. So, yes indeedy, the invoking user has
not access to /dev/cua1. Flipping the real and effective
uid/gid using setreuid/setregid around the ttylock/ttyunlock
calls will make the uucico effective user the real user for
testing device access within the /usr/sbin/lockdev exec
if desired.

ok, I think I understand the problem, but the solution eludes me.

in unix/serial.c: ttylock() is called to access the /dev file.

The /dev files are owned root.uucp

The real access is done by /usr/sbin/lockdev, which is sgid "lock", and will be
running either as the real user, or as user uucp. I put in a ulog, and at the
time of the ttylock, the uid is myself, the euid is uucp.

If I understand the strace correctly, uucico is stit running as the suid user
(which will be uucp), so lockdev will be run as user uucp, group lock, and this
is probably why it cannot access /dev/cua1 (own.grp as root.uucp)

in short, lockdev does not have access rights to the serial ports (/dev/cua*)

Yup. Changing from the real to the effective uid (i.e. uucp)
before doing the exec in baudboy.h is what might be needed.
Otherwise, forcing either root/uucp to run uucico is not
necessarily bad either.

I looked at baudboy.h

I decided to try your suggestion (above).

I have verified that at the time of the call to ttylock():

         uid (as returned by getuid) is 700 (that's my user id)
         euid (as returned by geteuid) is 10 (that's uucp)

as I understand the suggestion, I tried calling fsuser() to swap the uids.
I did this in unix/serial.c: fsserial_lockfile(). I verified that just before
calling ttylock (after my patch), uid is now 10, euid is 700

I then modified baudboy.h, and after the fork, and before the open of /dev/null
I print out the argv's and the uid. This is what I see.

        my uid is: 10, /usr/sbin/lockdev -l /dev/cua1

(uid gotten from getuid())

in baudboy.h, just before the switch on the returned exit code, I print out the
raw return code (call me pedantic). I see a "2"

        the return code(1) is: 2, /usr/sbin/lockdev -l /dev/cua1

I really do not understand how lockdev can be failing. If I su - uucp, I have
proper permissions to run lockdev (I have su'ed to uucp, and tried. it works).

oh wait. dim light going on. as I recall, setuid only sets the uid, it does not
change the group perms. and Exec does not setup a user environment (i.e. does
not go thru "login", and the exec'd process does not have the suid user's group
privs. Only the group privs from teh original user (but these are overwritten by
the sgid bit).


therefore, lockdev, running from uucp, is runing as whomever (either myself, or
uucp), and the group is forced to group lock (by the sgid bit).

ok, I think this is what is happening. If so, then lockdev will still not have
necessary access to /dev/cua* (they are root owned, group uucp).

I think lockdev will need to be suid root.

hmm. just tried this. still doesn't work.

        ls -l /usr/sbin/lockdev
        -rwsr-sr-x    1 root     lock   8332 Aug 29 03:08   /usr/sbin/lockdev


Now this is truely strange. If I run lockdev (suid root) as myself, it
definately works, and creates the LCK.. files in /var/lock as well (owned
"root.lock")

gotta be something with execv()

I'm over my head here, but hope this helps. I'm willing to try patches.

OK, the fix is going to be to put
    setregid(geteuid(),getuid())
just before the exec in baudboy.h from
lockdev-1.0.0-14, as that
is the right place to fix access(2) for
all setgid programs, not just uucp.

Fixed in uucp-1.06.1-31, rebuilt against lockdev-1.0.0-14.

Thanks for the help verifying the fix.

The src.rpm I got from Jeff before shipping was good (which is matches exactly
the lockdev/uucp
src.rpm's on Enigma)

I also note that if I take the rpms, build lockdev, install _both_ lockdev rpms,
and then build uucp
and install _that_ uucp rpm, uucico/uucp NOW will work.

Perhaps the build process is at fault, and the lockdev-devel rpm was not
installed when uucp
was built.

Should be fixed in -32. Really, we mean it.

According to the description, "Resolution Rawhide" should mean the problem is
fixed in the latest development version obtainable from the ftp site.  But I
can't find -32 available at any rawhide.

I'm having related problems, trying to use "cu" on a 7.2 system.  It appears to
be the same problem, lockdev failing since it uses my UID and GID, not the ones
of cu.

AFAIK these problem(s) have long since been resolved (but look for the
long pending, soon to happen, security errata re-release).

Please reopen if I'm wrong.