Bug 4135 - printfilter fails on NFS filesystem - bogus permission checks?
printfilter fails on NFS filesystem - bogus permission checks?
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-07-21 09:51 EDT by Vlado Potisk
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-08-21 19:53:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vlado Potisk 1999-07-21 09:51:53 EDT
Shell script named filter exists in
the printer spool directory defined
in the /etc/printcap.

This script fails if this directory
exists on an NFS file system. After moving
it to local filesystem the problem
disappeared.

The script fails when it is invoked
from lpd and trying to read its
standard input; error message is
Input/Outpuer error. The problem results
in a message "no way to print this file
type" (don't remember it exactly)
printed on the printer.
Comment 1 Bill Nottingham 1999-07-28 19:05:59 EDT
Works fine for me here when the spool directory is NFS
mounted - of course, it has to be mounted no_root_squash.
Comment 2 Vlado Potisk 1999-08-02 04:33:59 EDT
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@tempest.sk
Comment 3 Bill Nottingham 1999-08-02 12:26:59 EDT
What happens if you upgrade to the latest lpr package from
Raw Hide (0.39)?
Comment 4 Vlado Potisk 1999-08-03 05:11:59 EDT
After the upgrade I CAN print. No permission problem
anymore; the process runing 'filter' has now GID=lp
in its supplemental group list.
Comment 5 Bill Nottingham 1999-08-03 09:33:59 EDT
It's still odd that it would fail in the first place.
What permissions are you mounting the spool directory
with?
Comment 6 Vlado Potisk 1999-08-04 05:10:59 EDT
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.
Comment 7 Bill Nottingham 1999-08-04 10:22:59 EDT
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?
Comment 8 Vlado Potisk 1999-08-05 04:14:59 EDT
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.
Comment 9 Bill Nottingham 1999-08-21 19:53:59 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.