Date: Mon, 27 Dec 1999 13:20:53 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Alfred Perlstein <bright@wintelcom.net>, Andre Albsmeier <andre.albsmeier@mchp.siemens.de>, Warner Losh <imp@village.org>, current@FreeBSD.ORG Subject: Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test Message-ID: <v0421010db48d5966da31@[128.113.24.47]> In-Reply-To: <Pine.BSF.3.96.991224084725.28605A-100000@fledge.watson.org> References: <Pine.BSF.3.96.991224084725.28605A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 8:55 AM -0500 12/24/99, Robert Watson wrote: >... keep in mind that this optimization does not produce behavior >behavior in some cases. For example, imagine that the user has a >number of hard links to the file in question. If the file is copied and >then deleted, then the link count is decremented by one, and the data used >to print is independent of the original file. However, if a single file >system rename is used, the link count remains the same until the end of >the print job, and if any of the other references to the same inode are >modified, the print job will see inconsistent versions of the file (i.e., >it being changed out from under it). Hmm. This was a very good point to bring up, even if people don't use it to modify the file (or do anything else nefarious). The real problem here is that lpr changes the ownership and permissions of the file after moving it. That means that if the user does give us a file with multiple hard links, lpr will repermit *all* copies of the file, not just the version it moved into the spool directory. Clearly we also need to check the inode count. Thanks for that observation! >I do not know whether the current >lpr waits until it finishes copying before returning, but assume so, >meaning that once lpr returns, normally, you are guaranteed that unless >using the symlink option, you can continue to modify the inode in question >with impunity. With this optimization makes that assumption not true. A >caveat is already present for the symlink, "-s", option to this effect. I >believe this also allows users to present files that start out being >within the maximum file size when that is checked, but later add more, >allowing users to avoid the file size limit on print jobs. This is >presumably already present with "-s", and it's possible that lpd checks >for this. Well, for some reason lpr is dumber than that. The spooled datafile ends up being owned by the user who sent the job, and thus the user can go in any time and make changes. That's already true, without this update or '-s' being used. Personally I think that is bad, because it does allow the user to circumvent any checks done at job-submission time. I think I'll write a separate update for that (maybe next year... :-). --- 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-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v0421010db48d5966da31>