Red Hat Bugzilla – Bug 166155
ckermit cannot open lock file in /var/lock
Last modified: 2007-11-30 17:11:12 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6 Description of problem: ckermit tries to open a lock file for /dev/ttyS0 in /var/lock. However, this is wrong for two reasons. First, ckermit doesn't have write permission in /var/lock, and second, uucp opens its lock files in /var/lock/uucp. Kermit is also unable to open /dev/ttyS0, because by default that device is owned by root.uucp with mode 660. I have patched the .spec and makefile to correct these problems. Version-Release number of selected component (if applicable): ckermit-8.0.211-2.FC4 How reproducible: Always Steps to Reproduce: 1.start ckermit 2.set line /dev/ttyS0 Actual Results: I get the error message: C-Kermit>set line /dev/ttyS0 /var/lock Sorry, write access to UUCP lockfile directory denied. Expected Results: kermit should have successfully opened a lock file in /var/lock/uucp. Additional info: Here is a patch to the spec file: --- /usr/src/redhat/SPECS/ckermit.spec 2005-08-01 05:23:12.000000000 -0400 +++ ckermit.spec 2005-08-17 11:36:13.000000000 -0400 @@ -1,7 +1,7 @@ Summary: The quintessential all-purpose communications program Name: ckermit Version: 8.0.211 -Release: 2.FC4 +Release: 2.FC4.saf License: Special (see COPYING.TXT.gz) Group: Applications/Communications Source0: ftp://kermit.columbia.edu/kermit/archives/cku211.tar.gz @@ -13,6 +13,7 @@ Source10: ckermit.ini Source11: ckuker.nr Patch0: ckermit-8.0.209-gcc4.patch +Patch1: ckermit.lock.patch URL: http://www.columbia.edu/kermit/ BuildRequires: pam-devel BuildRequires: pkgconfig @@ -35,6 +36,7 @@ %prep %setup -q -c %patch0 -p1 -b .gcc4 +%patch1 -p1 -b .lock # XXX Swipe files from cku206, remove when added to cku208 tarball. cp %{SOURCE10} . @@ -75,7 +77,7 @@ %doc *.gz %dir %{_sysconfdir}/kermit %config(noreplace) %verify(not size mtime md5) %{_sysconfdir}/kermit/* -%attr(755, root, root) %{_bindir}/kermit +%attr(6555, uucp, uucp) %{_bindir}/kermit %{_mandir}/man1/kermit.1* %changelog Here is a patch to the makefile: --- ckermit-8.0.211/makefile.orig 2005-08-17 11:06:37.000000000 -0400 +++ ckermit-8.0.211/makefile 2005-08-17 11:07:50.000000000 -0400 @@ -5994,6 +5994,7 @@ @echo 'Making C-Kermit $(CKVER) for Linux on i386 with KRB,SRP,SSL...' $(MAKE) xermit KTARGET=$${KTARGET:-$(@)} "CC = gcc" "CC2 = gcc" \ "CFLAGS = -g -O -funsigned-char -pipe -DPOSIX -DLINUX -DNOCOTFMC \ + -DLOCK_DIR=\\\"/var/lock/uucp\\\" \ -DCK_AUTHENTICATION -DCK_KERBEROS -DKRB5 -DKRB4 -DKRB524 \ -DCK_ENCRYPTION -DCK_CAST -DCK_DES -DLIBDES -DCK_SSL -DCK_PAM -DZLIB \ -DCK_CURSES -DCK_POSIX_SIG -DTCPSOCKET -DLINUXFSSTND -DHAVE_CRYPT_H \ Basically, these patches change the lock file location, and change the owner/group/mode of the executable to give it the same permissions as enjoyed by uucico.
Created attachment 117841 [details] The spec file patch
Created attachment 117842 [details] The makefile patch
thx., but I think I have better solution: 1, I add -DHAVE_BAUDBOY to KFLAGS in ckermit.spec (but lockdev package have to be fixed before I build new release) 2, user must be in uucp group to do "set line /dev/ttyS0" see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=49908 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=58807
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163276
Agreed - baudboy.h is a better soln. for the basic locking mechanism. I assume that your intent is to have all packages that need serial ports to use baudboy.h eventually. At my location, I will probably "chgrp uucp kermit", and "chmod g+s kermit" so that my users don't have to be in the uucp group. Hopefully, that will work given your fix. Basically, we only use the serial ports to talk to the embedded HW that we build here. So, we have no security constraints on our serial ports. I understand that other sites look at this differently :-) I agree that the default should be highly secure, as long as folks like me can turn security off if that is more appropriate to the local environment. Thanks!
fixed in fc4 and devel.