Red Hat Bugzilla – Bug 52029
uucp in roswell2 still does not work.
Last modified: 2007-04-18 12:36:02 EDT
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):
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.
chamging ownership of /var/lock from root.lock to root.uucp allows uucico
to again work.
This defect is considered MUST-FIX for Fairfax.
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
for some reason, the new uucico thinks that the dial up port is
I note that the timestamp on the directory /var/lock/uucp/
changes to match the date/time I ussied the uucico command, if
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
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.
uucico -S lugs-server
as myself, I get the message
ERROR: All matching ports in use
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]
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
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)
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
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 ?
/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
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
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
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
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
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
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.