From owner-freebsd-questions Thu Apr 1 20: 2: 9 1999 Delivered-To: freebsd-questions@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 2592E15D2A for ; Thu, 1 Apr 1999 20:02:04 -0800 (PST) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.8.8) id XAA08950; Thu, 1 Apr 1999 23:00:51 -0500 (EST) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199904020400.XAA08950@cc942873-a.ewndsr1.nj.home.com> Subject: Re: Manpath strageness In-Reply-To: <19990401003008.B94041@scientia.demon.co.uk> from Ben Smithurst at "Apr 1, 99 00:30:08 am" To: ben@scientia.demon.co.uk (Ben Smithurst) Date: Thu, 1 Apr 1999 23:00:51 -0500 (EST) Cc: gjb@comkey.com.au, cjclark@home.com, freebsd-questions@FreeBSD.ORG Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ben Smithurst wrote, > Greg Black wrote: > > > If that doesn't make things clear, I'd run it under ktrace and see > > what it's doing. > > Unlikely to work. man(1) is setuid, and ktrace doesn't work for setuid > programs[0]. It would trace OK for root, but Crist is having the problem > with non-root users. You could turn off the setuid bit, but then the > situation would have changed. > > -- > [0] very annoying, though I suppose necessary for security really I eventually figured this out. I'd call it a bug. 'man' will fail to find a manpage if either of the files in the man* or cat* directories exists, but is unreadable. That is if, -r--r----- 1 man man 9809 Nov 22 13:07 /usr/local/man/man1/procmail.1.gz -r--r--r-- 1 man man 11488 Apr 1 21:21 /usr/local/man/cat1/procmail.1.gz The output of interest from 'man -d procmail' is, searching in /usr/local/man trying section 1 with globbing globbing /usr/local/man/man1/procmail.1* to_name in convert_name () is: /usr/local/man/cat1/procmail.1.gz will try to write /usr/local/man/cat1/procmail.1.gz if needed And then it continues to search until it runs out of places to look and it reports no page. If we have, -r--r--r-- 1 man man 9809 Nov 22 13:07 /usr/local/man/man1/procmail.1.gz -r--r----- 1 man man 11488 Apr 1 21:21 /usr/local/man/cat1/procmail.1.gz The debug output is, searching in /usr/local/man trying section 1 with globbing globbing /usr/local/man/man1/procmail.1* to_name in convert_name () is: /usr/local/man/cat1/procmail.1.gz will try to write /usr/local/man/cat1/procmail.1.gz if needed status from is_newer() = 0 And again, we then continue on until we run out of manpaths, and it claims no such page exists. However, if I _move_ the file in man1 so it will not be found at all, then we get, searching in /usr/local/man trying section 1 with globbing globbing /usr/local/man/man1/procmail.1* globbing /usr/local/man/man1/procmail.0* globbing /usr/local/man/cat1/procmail.1* trying command: /usr/bin/zcat /usr/local/man/cat1/procmail.1.gz | more That is, the command succeeds. Likewise, if I move the file in cat1 (and replace the one in man1), searching in /usr/local/man trying section 1 with globbing globbing /usr/local/man/man1/procmail.1* to_name in convert_name () is: /usr/local/man/cat1/procmail.1.gz will try to write /usr/local/man/cat1/procmail.1.gz if needed status from is_newer() = -2 using default preprocessor sequence mode of /usr/local/man/cat1/procmail.1.gz.tmpDo8089 is now 644 Formatting page, please wait... trying command: (cd /usr/local/man ; /usr/bin/zcat /usr/local/man/man1/procmail.1.gz | /usr/bin/tbl | /usr/bin/groff -Wall -mtty-char -Tascii -man | /usr/bin/col | /usr/bin/gzip -c) No output, debug mode. using default preprocessor sequence Couldn't open /usr/local/man/cat1/procmail.1.gz.tmpVh8089 for writing. using default preprocessor sequence trying command: (cd /usr/local/man ; /usr/bin/zcat /usr/local/man/man1/procmail.1.gz | /usr/bin/tbl | /usr/bin/groff -Wall -mtty-char -Tascii -man | /usr/bin/col | more) And it works! So to summarize, 'man' fails to find a page if one of the man-cat pair is readable and the other exists but has insufficent permissions[0] for the user to read it. But if one of the man-cat pair does not exist at all, and the other does, man will find the page. This seems incorrect to me. Shouldn't man treat a page it does not have permission to read just as if it was not there at all? I had a look at the source. I compiled a '-g' copy of man and ran gdb on it... and now my brain hurts. I think the problem lies in man/glob.c where it should treat a file that is found, but unreadable, as if it was not there at all. I plan to submit a PR once I can bear to look at this more. [0] The fact that man thinks it has insufficient permissions is in itself a bug. The manpages are all owned by man (as shown above), and 'man' is a setuid command, -r-sr-xr-x 1 man bin 28672 Feb 28 21:44 /usr/bin/man All of the pages should still readable as I have changed permissions above (o-r), but that _is_ the output I get. -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message