Bug 4135
| Summary: | printfilter fails on NFS filesystem - bogus permission checks? | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Vlado Potisk <reg.bugs> |
| Component: | kernel | Assignee: | David Lawrence <dkl> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.0 | ||
| 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: | 1999-08-21 23:53:21 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
Vlado Potisk
1999-07-21 13:51:53 UTC
Works fine for me here when the spool directory is NFS mounted - of course, it has to be mounted no_root_squash. Additional info: after each print attempt there is a message in the NFS server's syslog: kernel: fh_verify: hp1100/df..... permission failure So I checked the file permissions in the spool directory on my system (NFS client): - script named filter runs wtih UID=lp, GID=root - it read the df.... file from its standard input - that df.... file has UID=root, GID=lp, mode=660 (rw-rw----) - this means that process 'filter' is not able to open and read the df.... file - there is normally (i.e. without NFS) no problem with this, becasue 'filter' has already a valid open descriptor (stdin) for this df.... file - it seems to me that NFS checks during the read operation the file permissions of already open file and thus causes the described problem 02-AUG-1999 vlado_potisk What happens if you upgrade to the latest lpr package from Raw Hide (0.39)? After the upgrade I CAN print. No permission problem anymore; the process runing 'filter' has now GID=lp in its supplemental group list. It's still odd that it would fail in the first place. What permissions are you mounting the spool directory with? This the spool directory: /var/spool/lpd: drwxrwxr-x 3 root daemon 1024 Aug 3 19:43 . drwxr-xr-x 8 root root 1024 Jul 16 22:32 .. drwxr-xr-x 2 root lp 1024 Aug 2 21:51 hp1100 -rw-r--r-- 1 root root 4 Aug 3 18:47 lpd.lock /var/spool/lpd/hp1100: drwxr-xr-x 2 root lp 1024 Aug 2 21:51 . drwxrwxr-x 3 root daemon 1024 Aug 3 19:43 .. -rw-r----x 1 root lp 4 Aug 2 21:51 .seq -rwxr-xr-x 1 root root 9443 Jul 31 19:24 filter -rwxr-xr-x 1 root root 187 Jul 31 19:24 general.cfg -------rw- 1 root root 4 Aug 3 18:47 lock -rwxr-xr-x 1 root root 338 Jul 31 19:24 postscript.cfg -rw-rw-r-- 1 root root 33 Aug 2 21:51 status -rwxr-xr-x 1 root root 147 Jul 31 19:24 textonly.cfg Everything is on one root-NFS filesystem on a diskless PC. Hmm... comparing that to a spool directory here everything looks OK. Are both the server and client RH 6.0 machines, or are they something different? Both machines are running freshly installed RH6.0 plus some updates that were available at the time of installation. The kernel is 2.2.10, I have compiled it from the source, not installed from some RPM. Hardware is quite standard and stable. I was able to duplicate the bug also on only one machine exporting NFS filesystem to localhost. Hm... although I'm not sure while it's failing, it is fixed with the lpr update. I'm marking this fixed for now, and I'll look at the NFS issues later. |