Bug 49908
Summary: | uucp no longae work (because it cannot write to /var/lock) | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | greg hosler <greg> |
Component: | uucp | Assignee: | Jeff Johnson <jbj> |
Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.3 | CC: | jbj, nphilipp |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-08-16 13:48:39 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
greg hosler
2001-07-24 23:57:42 UTC
Problem also exists in Beta 3 (roswell) - when uucico -S <uucp host> is issued, the following is written to /var/messages: uucico lugs-server - (2001-07-31 22:32:23.95 1751) ERROR: creat (/var/lock/TMP00000006d7): Permission denied The reason is because /var/log is 755 root.root, and uucp (and all serial programs) are expecting it to be 775 root.uucp I have written a history of serial support in Unix, you will find it in the testers-list-admin archives. -Greg This is still the case, even with the latest changes to /var/lock in the filesystem. At the moment, I have to open up /var/lock completely in order for uucp to work (which is even worse than group-writable IMO). > This is still the case, even with the latest changes to /var/lock in the
> filesystem. At the moment, I have to open up /var/lock completely in order
> for uucp to work (which is even worse than group-writable IMO).
That is NOT TRUE. If you were at all familiar w/ uucp, you would KNOW this
to be NOT TRUE.
In order for UUCP to work, permissions of 775, and ownership of root.uucp
is perfectly adequate. It is, afterall, how it used to be set, and is, infact
by design.
If you move the lock directory to (for example), /var/lock/serial (or
/var/lock/uucp), you need only set that particular directory as 775, root.uucp,
and you can leave /var/lock 755 root.root
Note that that would be non-compliant with FHS 2.2
Note also that your current scheme of a hierarchy within /var/lock is itself
non-compliant with FHS 2.2 (the proper place for those directories would be
within /var/lib - see section 5.8 of the FHS 2.2 - While I do not expect you
to swap the stuff in /var/lock that should NOT be there (the sub directory
hierarchy, as well as console.lock), I do think that you should give serious
consideration to moving this stuff to /var/lib (where, in compliance with FHS,
it belongs) in RH 8.0
-Greg
Ahem, you seem to have misunderstood me completely. First: I'm not the owner of the uucp package and second this messages was a hint to jbj (the owner) that a recent change in a non-public release of the filesystem package didn't solve the problem either -- in fact it made it worse (I don't know whether I may disclose the details to you, so I leave it that way). I presume that there need to be some changes in the uucp package to work smoothly with the change in filesystem. And last: I am indeed familiar with UUCP, as my private mails depend on it working, thank you very much. I don't think that bugzilla is a place for ad hominem attacks. Ugh, strike jbj as the owner, set havill in the last comment. It's way too hot to think clearly ATM. The /var/lock directory is now root.lock 775. What remains for uucp is to use lockdev to create the device lock and check that uucp needs no other locks in /var/lock. There might still be a system lock created in /var/lock, hard to from just reading sources. Nils: Can you do chgrp uucp /usr/sbin/lockdev /var/lock chmod g+s /usr/sbin/lockdev and verify two things 1) Does uucp/minicom work with that scheme? 2) Are there any other uucp locks beside the device lock in /var/lock? If yeas and no are the answers, I can get uucp fixed pretty quickly. The above scheme should also provide a better alternative to "chmod 777 /var/lock" and is nearly as secure as the desired root.lock ownership. - uucp does work that way, the only lock is LCK..${peername} (I do UUCP over TCP) - minicom works, the lock files are: LCK...31613 LCK..ttyS0 LCK.004.064 -- apparently PID, device and something I don't recognize OK, I know what to do now. The LCK..${peername} is destined for /var/lock/uucp uucp.uucp 775, while the device lock will use lockdev in /var/lock. The other lock is major.minor IIRC. Thanks for the help. Fixed (but not yet verified) in uucp-1.06.1-29 and later. Changes there are 1) move uucp per-peer lock from /var/lock to 775 uucp.uucp /var/lock/uucp sub-directory. 2) use setgid lock helper /var/sbin/lockdev to create per-device lock file(s) in root.lock 775 /var/lock directory. Look for a uuxqt exploit fix in uucp-1.06.1-30 as well. |