Re: our broken man package
Late, by hey, what the hell... Joey == Joey Hess [EMAIL PROTECTED] writes: Joey In other words, if you can have a religious war over it, we Joey need an alternative. I have never seen a religious war over Joey man. :-) Tom Christiansen has been known to get into them. But then TomC has been known to get into a lot of religious wars. :) -- Stephen So if she weighs the same as a duck, she's made of wood And therefore?... A witch!
Re: our broken man package
On Thu, Jan 04, 2001 at 09:04:50AM +, Lars Wirzenius wrote: Ethan Benson [EMAIL PROTECTED]: OpenBSD took another tack on this problem and just did away with cached man pages altogether. (no suid or sgid man) They always re-format a manual page? This might be reasonable, actually. and some of them filter all the pages through tbl even if only 1/6 of them needs it. Groff is pretty fast, and most manual pages are short, so it shouldn't take too long even on older hardware. but some are soo big. Bash and perl* are good examples. And, anyway, caching might be done in a cronjob: look at the pages in manpath every night, check which ones have been accessed since the past run, and format those. Then delete anything older than N days in the cache. When displaying, use the cached version only if it is newer than the source. Lars, this is exactly the way it works today. Apart from your strange idea to cache what has been accessed during the day. As caching is done at access time, they are already cached! The actual cron.daily removes them after 6 days. And the cached version is used not only if it's newer then the source, but also if the you specifyed the same preprocessor options. This info is stored in the db. While makewhatis only collects name+description, mandb also stores timestamp, formatting options and type of file. I'm planning to add caching not only for ascii formatted pages, but also for html output (which is now available directly from groff). In this case preformatting all pages would be interesting. On the other hand, we might want to copy the OpenBSD version instead of maintaining our own man. But I leave that to whoever maintains the packages. I would prefere the man in plan9. It's the cleaner and simpler I've ever seen. fab -- | [EMAIL PROTECTED][EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
Re: our broken man package
On Fri, Jan 05, 2001 at 01:09:17AM -0300, Nicolás Lichtmaier wrote: There could be a helper setuid program, man-cache-writer. man would call this program and pipe it the catpage. man-cache-writer would just write it's stding to the proper place. End of the problems. No so simple. You don't want the trusted program trusting the output of a non-trusted program. A start to fix the current problems is to: 1. drop privs if reading a man page that's not going to be cached anyway. (E.g., a page in your private home directory.) 2. and in that case ignore tmpdir. store temporary files in a directory writable only my user man. -- Mike Stone
Re: our broken man package
There could be a helper setuid program, man-cache-writer. man would call this program and pipe it the catpage. man-cache-writer would just write it's stding to the proper place. End of the problems. No so simple. You don't want the trusted program trusting the output of a non-trusted program. Qhat if the man binary is setgid man, and this utility can only be run by that group? A start to fix the current problems is to: 1. drop privs if reading a man page that's not going to be cached anyway. (E.g., a page in your private home directory.) 2. and in that case ignore tmpdir. store temporary files in a directory writable only my user man. That seems sensible.
Re: our broken man package
On 04-Jan-01, 12:32 (CST), Joey Hess [EMAIL PROTECTED] wrote: Lars Wirzenius wrote: And, anyway, caching might be done in a cronjob: look at the pagesa in manpath every night, check which ones have been accessed since the past run, and format those. Then delete anything older than N days in the cache. When displaying, use the cached version only if it is newer than the source. That's a good idea. The only (small) problem is that you don't cache the first day. Thus the sequence man bash try something man bash try something else man bash (etc...) results in the bash man page being formatted each time. (Yeah, if I *knew* was going to be looking at it several times, I'd save it myself, or use another window/console, but it never seems to work out that way.) Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: our broken man package
Hi Joey Hess schrieb: And, anyway, caching might be done in a cronjob: look at the pagesa in This seems to be cr^Hontrary to the idea of caching. That's a good idea. Another route to take is to split man into the rendering/caching bit and the command line man page lookup/processing/pager executing bit. Only the former part of the program needs to run as user man, A man-daemon? Or a 6755 root.man rendering part? Wouldn't simpy let every user have his own cache be much simpler and not even too much worse, since different users tend to read different manpages? A cronjob could collect these per-user cached pages into a shared cache if this is really needed, and clean up the user caches. ciao, 2ri -- All constants are variables.
Re: our broken man package
On Wed, Jan 03, 2001 at 03:23:03PM -0800, Joey Hess wrote: I'm concerned with some breakage in the man program. Here is an example: [snip examples] This is because man runs via a wrapper that makes it run as user man (and makes root's pager run as user man too for some reason). Related bugs: #74790, #60084, #58112, #42128. I have never seen an explination of why this wrapper program makes man run as user man. If it just ran it as group man, everything would be ok. As bug #42128 suggests, /var/catman/ could be writable by group man, rather than user man. the problem with this is you end up with the catman files owned by whatever user reads whatever man page. personally as a sysadmin i don't want users gaining write permission to files in any more places under /var then there already is (ahem texmf). i am not certain if there is potential security threats to users being able to write bogus catman files, perhaps via groff tricks there is. IMO a setgid man with a group writable /var/catman is not any better then a mode 1777 /var/catman. (which is what slackware does btw) OpenBSD took another tack on this problem and just did away with cached man pages altogether. (no suid or sgid man) -- Ethan Benson http://www.alaska.net/~erbenson/ pgp1CiH8rxzJQ.pgp Description: PGP signature
Re: our broken man package
Ethan Benson wrote: the problem with this is you end up with the catman files owned by whatever user reads whatever man page. personally as a sysadmin i don't want users gaining write permission to files in any more places under /var then there already is (ahem texmf). i am not certain if there is potential security threats to users being able to write bogus catman files, perhaps via groff tricks there is. I'll bet (have not verified) that you can already trick it into writing bogus file by sticking trojan pages elsewhere in your manpath. IMO a setgid man with a group writable /var/catman is not any better then a mode 1777 /var/catman. (which is what slackware does btw) OpenBSD took another tack on this problem and just did away with cached man pages altogether. (no suid or sgid man) -- see shy jo
Re: our broken man package
On Wed, Jan 03, 2001 at 11:53:37PM -0800, Joey Hess wrote: Ethan Benson wrote: the problem with this is you end up with the catman files owned by whatever user reads whatever man page. personally as a sysadmin i don't want users gaining write permission to files in any more places under /var then there already is (ahem texmf). i am not certain if there is potential security threats to users being able to write bogus catman files, perhaps via groff tricks there is. I'll bet (have not verified) that you can already trick it into writing bogus file by sticking trojan pages elsewhere in your manpath. i just tried it, did not end up with a cached file. [EMAIL PROTECTED] eb]$ export MANPATH=/home/eb/test [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*' [EMAIL PROTECTED] eb]$ ls -l /home/eb/test/man8/ total 8 -rw-r--r--1 eb eb 5193 Jan 3 23:03 bogus.8 [EMAIL PROTECTED] eb]$ man bogus Reformatting bogus(8), please wait... ... [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*' it also doesn't cache anything when pointing man directly at a specific man page: [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'yaboot*' [EMAIL PROTECTED] eb]$ man devel/ybin/man/yaboot.8 Reformatting yaboot.8, please wait... ... [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'yaboot*' [EMAIL PROTECTED] eb]$ and yes my caching does work as you can see for a normal man page: [EMAIL PROTECTED] eb]$ man yaboot Reformatting yaboot(8), please wait... ... [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'yaboot*' /var/cache/man/cat8/yaboot.8.gz -- Ethan Benson http://www.alaska.net/~erbenson/ pgpKKDIEKxmZF.pgp Description: PGP signature
Re: our broken man package
Lars Wirzenius [EMAIL PROTECTED] writes: On the other hand, we might want to copy the OpenBSD version instead of maintaining our own man. But I leave that to whoever maintains the packages. We have alternatives on almost everything but dpkg and man. If someone thinks it's worth the effort to make alternatives for these they should do it. If there is a general agreement that the alternatives is better than the original packages we just switch prioryties. So simple is that.
Re: our broken man package
On Thu, Jan 04, 2001 at 11:00:19AM +0100, Peter Makholm wrote: Lars Wirzenius [EMAIL PROTECTED] writes: On the other hand, we might want to copy the OpenBSD version instead of maintaining our own man. But I leave that to whoever maintains the packages. We have alternatives on almost everything but dpkg and man. If someone thinks it's worth the effort to make alternatives for these they should do it. If there is a general agreement that the alternatives is better than the original packages we just switch prioryties. So simple is that. Well, I'll take a look at as many of these issues as I can this weekend, when I re-package groff and man-db. I've got some time on my hands; thanks to testing, it will be almost another week before XFree86 4.x gets in there. -- G. Branden Robinson |Software engineering: that part of Debian GNU/Linux|computer science which is too difficult [EMAIL PROTECTED] |for the computer scientist. http://www.debian.org/~branden/ | pgpQZCIjxuz6Y.pgp Description: PGP signature
Re: our broken man package
Ethan Benson [EMAIL PROTECTED] wrote: On Wed, Jan 03, 2001 at 11:53:37PM -0800, Joey Hess wrote: I'll bet (have not verified) that you can already trick it into writing bogus file by sticking trojan pages elsewhere in your manpath. i just tried it, did not end up with a cached file. [EMAIL PROTECTED] eb]$ export MANPATH=/home/eb/test [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*' [EMAIL PROTECTED] eb]$ ls -l /home/eb/test/man8/ total 8 -rw-r--r--1 eb eb 5193 Jan 3 23:03 bogus.8 [EMAIL PROTECTED] eb]$ man bogus Reformatting bogus(8), please wait... ... [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*' Yes, there's no MANDB_MAP entry in /etc/manpath.config for /home/eb/test. 'MANPATH=/home/eb/test manpath -c' will tell you the catpath corresponding to a given manpath. I don't know if it's possible to subvert this. -- Colin Watson [EMAIL PROTECTED]
Re: our broken man package
Lars Wirzenius wrote: They always re-format a manual page? This might be reasonable, actually. Groff is pretty fast, and most manual pages are short, so it shouldn't take too long even on older hardware. I think it would take a while on my 386 for things like the zshall man page. (Several hundred pages of documentation.) And, anyway, caching might be done in a cronjob: look at the pagesa in manpath every night, check which ones have been accessed since the past run, and format those. Then delete anything older than N days in the cache. When displaying, use the cached version only if it is newer than the source. That's a good idea. Another route to take is to split man into the rendering/caching bit and the command line man page lookup/processing/pager executing bit. Only the former part of the program needs to run as user man, and it could be a fairly small and more auditable peicve of code. This would also happen to solve most of the reported bugs with the current setup. Though I think I like your idea better. -- see shy jo
Re: our broken man package
Peter Makholm wrote: We have alternatives on almost everything but dpkg and man. If someone thinks it's worth the effort to make alternatives for these they should do it. If there is a general agreement that the alternatives is better than the original packages we just switch prioryties. Is that even necessary? I mean, alternatives makes sense for programs like MTAs and editors, which have a diverse range of interface, functionality, and use. Man formats a page and displays it in $PAGER; its usage is pretty set in stone since a long time ago. One man program might be faster or more secure, or less buggy than another, but it's going to look and operate the same, so it seems everyone is going to gravitate to the best one available, so why bother with alternatives for the rest? In other words, if you can have a religious war over it, we need an alternative. I have never seen a religious war over man. :-) -- see shy jo
Re: our broken man package
On Thu, 4 Jan 2001, Joey Hess wrote: JHPeter Makholm wrote: JH We have alternatives on almost everything but dpkg and man. If someone JH thinks it's worth the effort to make alternatives for these they JH should do it. If there is a general agreement that the alternatives is JH better than the original packages we just switch prioryties. JH JHIs that even necessary? I mean, alternatives makes sense for programs JHlike MTAs and editors, which have a diverse range of interface, JHfunctionality, and use. Man formats a page and displays it in $PAGER; JHits usage is pretty set in stone since a long time ago. One man program JHmight be faster or more secure, or less buggy than another, but it's JHgoing to look and operate the same, so it seems everyone is going to JHgravitate to the best one available, so why bother with alternatives for JHthe rest? JH JHIn other words, if you can have a religious war over it, we need an JHalternative. I have never seen a religious war over man. :-) Never heard RMS on info pages? JH -- Pardon me, but you have obviously mistaken me for someone who gives a damn. email [EMAIL PROTECTED]
Re: our broken man package
John Galt wrote: JHIn other words, if you can have a religious war over it, we need an JHalternative. I have never seen a religious war over man. :-) Never heard RMS on info pages? That's a file format religious war, not a man program religious war. -- see shy jo
Re: our broken man package
On Thu, 4 Jan 2001, Joey Hess wrote: JHJohn Galt wrote: JH JHIn other words, if you can have a religious war over it, we need an JH JHalternative. I have never seen a religious war over man. :-) JH JH Never heard RMS on info pages? JH JHThat's a file format religious war, not a man program religious war. /etc/alternatives/help-file-format? :) JH -- Pardon me, but you have obviously mistaken me for someone who gives a damn. email [EMAIL PROTECTED]
Re: our broken man package
On Thu, Jan 04, 2001 at 10:35:56AM -0800, Joey Hess wrote: Is that even necessary? I mean, alternatives makes sense for programs like MTAs and editors, which have a diverse range of interface, functionality, and use. Man formats a page and displays it in $PAGER; I'd always thought the intention was exactly the opposite - where one doesn't care which program one gets so long as it provides the functionality required one uses an alternative. If, for example, I run /usr/bin/vi I expect to get something that understands standard vi commands and command line arguments. It's just that there are multiple programs that can do this and each of these programs can have additional features so you might want to have a seleciton installed simultaneously. its usage is pretty set in stone since a long time ago. One man program might be faster or more secure, or less buggy than another, but it's going to look and operate the same, so it seems everyone is going to gravitate to the best one available, so why bother with alternatives for the rest? Of course, this also makes sense. Perhaps if multiple man programs are packaged it would be more useful for them to conflict with each other and just include the man executable directly. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgp6z1ZrqSaQO.pgp Description: PGP signature
Re: our broken man package
Joey Hess wrote:
I'm concerned with some breakage in the man program. Here is an example:
[EMAIL PROTECTED]:~chmod 700 .
[EMAIL PROTECTED]:~cp /usr/share/man/man1/ls.1.gz .
[EMAIL PROTECTED]:~man -l ./ls.1.gz
man: can't chdir to /home/joey: Permission denied
man: ./ls.1.gz: Permission denied
Another example (only works as root):
[EMAIL PROTECTED]:~cp /bin/more bin/mymore
[EMAIL PROTECTED]:~PAGER=~/bin/mymore man man
sh: /root/bin/mymore: Permission denied
man: command exited with status 32256: /bin/gzip -dc
'/var/cache/man/cat1/man.1.gz' | { export MAN_PN LESS; MAN_PN='man(1)';
LESS=$LESS\$-Pm\:\$ix8mPm Manual page $MAN_PN ?ltline %lt?L/%L.:byte
%bB?s/%s..?e (END):?pB %pB\\%..; /root/bin/mymore; }
Here's one more real fun one. This only works if you are root and /root
is mode 700 and $TMP is set to /root/tmp/:
[EMAIL PROTECTED]:~man man
man: can't create a temporary filename: Permission denied
So incredibly broken..
--
see shy jo
Re: our broken man package
the problem with this is you end up with the catman files owned by whatever user reads whatever man page. personally as a sysadmin i don't want users gaining write permission to files in any more places under /var then there already is (ahem texmf). i am not certain if there is potential security threats to users being able to write bogus catman files, perhaps via groff tricks there is. There could be a helper setuid program, man-cache-writer. man would call this program and pipe it the catpage. man-cache-writer would just write it's stding to the proper place. End of the problems.
Re: our broken man package
On Thu, Jan 04, 2001 at 07:14:13PM -0800, Joey Hess wrote: Here's one more real fun one. This only works if you are root and /root is mode 700 and $TMP is set to /root/tmp/: [EMAIL PROTECTED]:~man man man: can't create a temporary filename: Permission denied So incredibly broken.. here is one that is even more fun as works for any user: [EMAIL PROTECTED] /tmp]$ ls -ld . drwxrwxrwt6 root root 2048 Jan 4 20:33 . [EMAIL PROTECTED] /tmp]$ cp /usr/share/man/man1/ls.1.gz . [EMAIL PROTECTED] /tmp]$ ls -l ./ls.1.gz -rw-r--r--1 eb eb 2271 Jan 4 20:34 ./ls.1.gz [EMAIL PROTECTED] /tmp]$ man ./ls.1.gz ./ls.1.gz: No such file or directory man: can't remove /tmp/zmanZNdPIa: No such file or directory [EMAIL PROTECTED] /tmp]$ gunzip ls.1.gz [EMAIL PROTECTED] /tmp]$ man ./ls.1 Reformatting ls.1, please wait... ... [EMAIL PROTECTED] /tmp]$ this one is the wrapper's fault, it does a chdir() somewhere and then gzip doesn't find the page (since it gets a relative pathname). -- Ethan Benson http://www.alaska.net/~erbenson/ pgpkyqZNkMlCj.pgp Description: PGP signature
our broken man package
I'm concerned with some breakage in the man program. Here is an example:
[EMAIL PROTECTED]:~chmod 700 .
[EMAIL PROTECTED]:~cp /usr/share/man/man1/ls.1.gz .
[EMAIL PROTECTED]:~man -l ./ls.1.gz
man: can't chdir to /home/joey: Permission denied
man: ./ls.1.gz: Permission denied
Another example (only works as root):
[EMAIL PROTECTED]:~cp /bin/more bin/mymore
[EMAIL PROTECTED]:~PAGER=~/bin/mymore man man
sh: /root/bin/mymore: Permission denied
man: command exited with status 32256: /bin/gzip -dc
'/var/cache/man/cat1/man.1.gz' | { export MAN_PN LESS; MAN_PN='man(1)';
LESS=$LESS\$-Pm\:\$ix8mPm Manual page $MAN_PN ?ltline %lt?L/%L.:byte
%bB?s/%s..?e (END):?pB %pB\\%..; /root/bin/mymore; }
This is because man runs via a wrapper that makes it run as user man
(and makes root's pager run as user man too for some reason).
Related bugs: #74790, #60084, #58112, #42128.
I have never seen an explination of why this wrapper program makes man
run as user man. If it just ran it as group man, everything would be ok.
As bug #42128 suggests, /var/catman/ could be writable by group man,
rather than user man.
(I'm also concerned with the huge number of open and very old bugs that
exist against man-db, and the fact that debian is using a different man
program than every other distribution, and one that seems inferior to
boot (see bug #25410).)
--
see shy jo
