Date: Fri, 10 Dec 1999 12:20:55 -0800 (PST) From: Alfred Perlstein <bright@wintelcom.net> To: Garance A Drosihn <drosih@rpi.edu> Cc: 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: <Pine.BSF.4.21.9912101220360.4557-100000@fw.wintelcom.net> In-Reply-To: <v04210109b476ee7e06ca@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 10 Dec 1999, Garance A Drosihn wrote: > At 2:33 AM -0800 12/10/99, Alfred Perlstein wrote: > >Can someone take a look at this? > > > >Basically, it makes the link to the file, if it can unlink the original > >it will then chown the spool file if it can't delete or read the original > >then the user didn't have permission and it backs out. > > I'm thinking you'd what to add an lstat call after creating the > hardlink. Check the new file to see if it's a symlink, and if it > is, then delete the new file and go to nohardlink. Then proceed > with the rest of your code (which looks fine to me, but remember > I'm the guy who wrote a message explicitly for one mailing list, > and then sent it to the other one...). > > I'm not sure on that, and haven't had time to look at the code > yet. I'm just wondering about the case where a user might do a > lpr -r -s somesymlink > and want to be sure this does the right thing. I suspect that > currently (without this patch) lpr will copy the REAL file, and > then remove the symlink. I don't think we want to hard-link to > the symlink, and then remove the original symlink. > > Remember, my mind is tired enough that I could easily be making > things up here... It may be that the situation I'm wondering > about is already covered by other checks in the code. ugh, good call. i'll look into it. -Alfred 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?Pine.BSF.4.21.9912101220360.4557-100000>