From owner-freebsd-hackers Tue Aug 17 18:29:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 6FAC514F3A for ; Tue, 17 Aug 1999 18:29:40 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id VAA30116 for ; Tue, 17 Aug 1999 21:30:12 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Tue, 17 Aug 1999 21:30:30 -0400 To: hackers@FreeBSD.org From: Garance A Drosihn Subject: lpd security check for changed-file vs NFS Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG lpr has the '-s' option that tells it to create a symlink to the file you want to print, instead of copying the file into the spool directory. As a security precaution, it does a 'stat' call on the file it links to, and saves away the device_id and file_number that it found. When lpd later goes to print the file, it also does a stat to make sure it's getting the same file that the user originally specified on lpr. (so the user can't play games and use lpr to print out a file they have no access to) Generally, this works fine. Last week we updated a few critical administration boxes to use the same lpr/lpd we use everywhere else. They are on an AIX box (as are many of our workstations), but they also happen to mount many directories via NFS from another AIX box (which happens just about nowhere else on campus). It turns out this symlink check does not seem to work on files serviced up from an AIX box working as an NFS server. This was super- critical-urgent-die-die-die, so my quick fix was to just change my version of lpd to ignore the error if the file in question was NFS-mounted. (I used fstatvfs to find that out). - - - That's the background -- now the hacker-type question. Is there some other check I could use to make sure the file has not changed, if the standard st_dev+st_ino check is not going to work? Seems to me I should be checking something, instead of just ignoring the issue for NFS mounts (*all* NFS mounts, because I can't tell if the NFS server is AIX). Maybe do some sort of MD5 checksum of the first thousand bytes of the file? Any other suggestions? --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message