Bug 52029

Summary: uucp in roswell2 still does not work.
Product: [Retired] Red Hat Linux Reporter: greg hosler <greg>
Component: uucpAssignee: Eido Inoue <havill>
Status: CLOSED WORKSFORME QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: goeran, jbj
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-12-05 22:08:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
strace output none

Description greg hosler 2001-08-19 09:37:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.7-2smp i686; Nav)

Description of problem:
Not sure if uucp is supposed to work in roswell2 or not. I am guessing that
by the change in ownership of /var/lock to root.lock that the intention is
for uucp to work. However it does not.

doing uucico -S <system to call> gives the following error messages in

uucico lugs-server - (2001-08-19 18:00:45.85 1849) ERROR: creat
(/var/lock/TMP0000000739): Permission denied
uucico lugs-server - (2001-08-19 18:00:45.85 1849) ERROR: System already
Can not open file : /proc/stat

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. setup uucp. if it makes a difference, I am using "old" configuration
files. I place my "HDB" config files in /etc/uucp/old

2. do uucico -S <system to call>

3. tail /var/log/uucp/Log  for error messages.


Actual Results:  uucico fails to make the call.

Expected Results:  uucico should have made the call.

Additional info:

chamging ownership of /var/lock from root.lock to root.uucp allows uucico
to again work.

Comment 1 Glen Foster 2001-08-20 19:18:29 UTC
This defect is considered MUST-FIX for Fairfax.

Comment 2 Bill Nottingham 2001-08-30 16:13:18 UTC
Can you test uucp-1.06.1-30 - does that work for you?

Comment 3 Bill Nottingham 2001-08-30 16:22:08 UTC
Can you test uucp-1.06.1-30 - does that work for you?

Comment 4 greg hosler 2001-08-31 11:12:24 UTC
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

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.


Comment 5 Jeff Johnson 2001-08-31 12:23:49 UTC
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.

Comment 6 greg hosler 2001-08-31 12:41:54 UTC
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/

Comment 7 greg hosler 2001-08-31 12:44:26 UTC
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.

Comment 8 greg hosler 2001-08-31 12:46:21 UTC
Created attachment 30294 [details]
strace output

Comment 9 Jeff Johnson 2001-08-31 13:06:06 UTC
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.

Comment 10 greg hosler 2001-08-31 13:48:56 UTC
yes, uucico works as expected if I su root, or su uucp

(which strongly suggests that uucico is dropping privs)


Comment 11 Jeff Johnson 2001-08-31 14:05:22 UTC
uucico dropping privs is a different problem than device locking,
so I'm outta here :-)

We now return you to previously scheduled programming ...

Comment 12 greg hosler 2001-08-31 15:52:06 UTC
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:


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 ?

Comment 13 Jeff Johnson 2001-08-31 16:13:01 UTC
/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.

Comment 14 greg hosler 2001-08-31 23:01:59 UTC
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*)

Comment 15 Jeff Johnson 2001-09-01 11:34:15 UTC
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.

Comment 16 greg hosler 2001-09-01 14:55:22 UTC
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

gotta be something with execv()

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

Comment 17 Jeff Johnson 2001-09-04 17:53:56 UTC
OK, the fix is going to be to put
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.

Comment 18 greg hosler 2001-09-11 14:09:59 UTC
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.

Comment 19 Bill Nottingham 2001-10-02 06:14:56 UTC
Should be fixed in -32. Really, we mean it.

Comment 20 Göran Uddeborg 2001-12-05 22:07:58 UTC
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.

Comment 21 Jeff Johnson 2002-02-01 21:52:09 UTC
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.