|Summary:||uucp in roswell2 still does not work.|
|Product:||[Retired] Red Hat Linux||Reporter:||greg hosler <greg>|
|Component:||uucp||Assignee:||Eido Inoue <havill>|
|Status:||CLOSED WORKSFORME||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2001-12-05 22:08:04 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 /var/log/uucp/Log 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 locked Can not open file : /proc/stat Version-Release number of selected component (if applicable): How reproducible: Always 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 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
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 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) -Greg
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: 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 ?
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 "root.lock") 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 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.
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.