Date: Thu, 1 Apr 1999 23:00:51 -0500 (EST) From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: ben@scientia.demon.co.uk (Ben Smithurst) Cc: gjb@comkey.com.au, cjclark@home.com, freebsd-questions@FreeBSD.ORG Subject: Re: Manpath strageness Message-ID: <199904020400.XAA08950@cc942873-a.ewndsr1.nj.home.com> In-Reply-To: <19990401003008.B94041@scientia.demon.co.uk> from Ben Smithurst at "Apr 1, 99 00:30:08 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904020400.XAA08950>