I tried to post this question into freebsd-current but without response from commiters some time ago. So maybe in freebsd-hackers: -- Is anybody capable to solve or fix bin/7973 in lpd? I have found the problem is still there (FreeBSD-3.2). Or am I anything missing/doing wrong? bin/7973: Bad control file owner in case of remote printing. The problem is that print filters ("if" in printcap) cannot read control files cf* in case of remote printing (in case of local printing everything is ok). -- I think there are three possible solutions: 1) Close bin/7973, do nothing and say: Yes, we want this inconsistency between local and remote printing to be there. 2) Remove fchown() call from lpr.c (in case of local printing). 3) Apply my or another fix for this problem (in case of remote printing). Here is a new patch for 3.0-STABLE branch: -- "$FreeBSD: src/usr.sbin/lpr/lpd/recvjob.c,v 1.13.2.1 1999/08/29 15:43:25 peter Exp $"; *** recvjob.c.bad Thu Sep 2 10:04:46 1999 --- recvjob.c Thu Sep 2 10:21:22 1999 *************** *** 79,85 **** static int noresponse __P((void)); static void rcleanup __P((int)); static int read_number __P((char *)); ! static int readfile __P((char *, int)); static int readjob __P((struct printer *pp)); --- 79,85 ---- static int noresponse __P((void)); static void rcleanup __P((int)); static int read_number __P((char *)); ! static int readfile __P((char *, int, struct printer *)); static int readjob __P((struct printer *pp)); *************** *** 192,198 **** (void) write(1, "\2", 1); continue; } ! if (!readfile(tfname, size)) { rcleanup(0); continue; } --- 192,198 ---- (void) write(1, "\2", 1); continue; } ! if (!readfile(tfname, size, pp)) { rcleanup(0); continue; } *************** *** 218,224 **** if (strchr(dfname, '/')) frecverr("readjob: %s: illegal path name", dfname); ! (void) readfile(dfname, size); continue; } frecverr("protocol screwup: %s", line); --- 218,224 ---- if (strchr(dfname, '/')) frecverr("readjob: %s: illegal path name", dfname); ! (void) readfile(dfname, size, NULL); continue; } frecverr("protocol screwup: %s", line); *************** *** 229,237 **** * Read files send by lpd and copy them to the spooling directory. */ static int ! readfile(file, size) char *file; int size; { register char *cp; char buf[BUFSIZ]; --- 229,238 ---- * Read files send by lpd and copy them to the spooling directory. */ static int ! readfile(file, size, pp) char *file; int size; + struct printer *pp; { register char *cp; char buf[BUFSIZ]; *************** *** 241,246 **** --- 242,251 ---- fd = open(file, O_CREAT|O_EXCL|O_WRONLY, FILMOD); if (fd < 0) frecverr("readfile: %s: illegal path name: %m", file); + if (pp != NULL) + /* owned by daemon for protection */ + (void) fchown(fd, pp->daemon_user, -1); + ack(); err = 0; for (i = 0; i < size; i += BUFSIZ) { -- And here is cut from subsequent discussion: -- > Why would the filter be reading the control file? It is just a > filter, supposedly reading from stdin and writing to stdout... Yes and not. You can look into apsfilter for example. It gets from control file JOB, USER and HOST items in case of ASCII input printing. This information is used for "better" printing - ASCII input is converted into PostScript and some additional headers are added: "Printed by USER from HOST', "JOB name", date of printing and others. Why we should lose this feature? (But I don't know, if there is any other and better way how to fix this problem.) -- -- Rudolf Cejka ([EMAIL PROTECTED]; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message