BTS

Issue19

Title Upload Close
Priority wish Status resolved
Superseder Nosy List maddi, mika
Assigned To maddi Topics zsh

Created on 2006-11-26.08:02:09 by maddi, last changed 2006-12-02.18:00:04 by mika.

Files
File name Uploaded Type Edit Remove
readoptions.vim maddi, 2006-11-26.15:16:28 application/octet-stream
Messages
msg72 (view) Author: mika Date: 2006-12-02.18:00:04
We believe that your issue has been closed by the upload of
Version 0.9.2 of grml-scripts from Michael Prokop <mika@grml.org>.
The explanation is attached below

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat,  2 Dec 2006 18:46:31 +0100
Source: grml-scripts
Binary: grml-scripts
Architecture: source i386
Version: 0.9.2
Distribution: unstable
Urgency: low
Maintainer: Michael Prokop <mika@grml.org>
Changed-By: Michael Prokop <mika@grml.org>
Description: 
 grml-scripts - some small scripts which should make life easier
Changes: 
 grml-scripts (0.9.2) unstable; urgency=low
 .
   * fma has been renamed into qma. Supports "directly jump to
     keyword" now. (Closes: issue19)
Files: 
 33bb5576baf1fe398a2266e4494aa644 559 utils optional grml-scripts_0.9.2.dsc
 de73a28de5844d74bfa5e569fbcee60c 194623 utils optional grml-scripts_0.9.2.tar.gz
 195d1e782198ebf0714005b29c9361dc 212610 utils optional grml-scripts_0.9.2_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFcbzT2N9T+zficugRAhyeAJ9FMpqJA2acypJ9PydqDs+ikx9TZgCfcViJ
pNpUc84fo4Sfi8t5XU4pBXI=
=b4O4
-----END PGP SIGNATURE-----
msg58 (view) Author: matthi Date: 2006-12-01.06:57:25
On Wed, Nov 29, 2006 at 08:56:24PM +0000, Michael Prokop:
> /tmp/man is absolutely no option, because of security reasons and because /tmp 
> is autocleaned by default on every single (re)boot.

I have many difficulties to consider all these things sadly
until I totally understand everything that is involved which
needs time. So of course you know what to do by having the
whole core team at hand and having the overview because huge
parts were created by you.
I seem to not understand why reading the manpage in /tmp/man
is a security problem if privileges were dropped to someone
not being able to do more than reading.
And I would not even care about root not being able to use
qma [ formerly known as fma ] at all.
qma is hackish. It's better than the default reading
manpages. IMO it's no real solution and that's why i seek to
find a solution for this being the default for some future.
It probably will never work as long as we are not able to
find some big compagnions in the debian team which is.....
not possible AFAIK. That would change a much too long
tradition of using gzip for everything and whatever else is
involved. But who knows. Many people would have never
thought that compress would be replaced by gzip or gzip
replaced by bzip2 [ more memory involved ] ... and so on.

> And ~/grml/man does not exist as well on every system as user with uid 1000 
> must not be named 'grml'. And user root definitely should stay out of /home/
> $USER.

Lets not care about root, please. He should be able to use
something else or not use qma at all. Why being pressed to
read manpages as root at all? privileges dropping where at
all possible is the thing. I feel not good when reading
manpages as root at all. [ Might be a little paranoid, I am
sure ] but I would like to use an rsbac based kernel for sure
:) [ rsbac.org just for the record ]. It's a crying shame
all people talk about selinux and apparmor and too many never ever heard
about a project that has been started in the mid-nineties.

> Sorry, that's just too hackish for integration into a distribution. We have to 
> find a much cleaner solution.

I think there is not a much cleaner solution and qma is
still  too hackish.
Well after thinking about it I might drop the case of
wanting manzsh using lzop. There are much more important
issues than a little quicker manpage access :)

                Kudos, Maddi
msg54 (view) Author: mika Date: 2006-11-29.20:56:24
Well, you wanted to use ~/man/ for it and for root that would be /root/man/.

/tmp/man is absolutely no option, because of security reasons and because /tmp 
is autocleaned by default on every single (re)boot.

And ~/grml/man does not exist as well on every system as user with uid 1000 
must not be named 'grml'. And user root definitely should stay out of /home/
$USER.

Sorry, that's just too hackish for integration into a distribution. We have to 
find a much cleaner solution.
msg53 (view) Author: maddi Date: 2006-11-29.16:37:35
On Sun, Nov 26, 2006 at 04:23:52PM +0000, Michael Prokop:
> 
> Michael Prokop <mika@grml.org> added the comment:
> 
> Shipping ~/man/zshall.txt.lzo is not an option, for example user root would 
> never get that. So if we want to change manzsh we must find another way...
> 

I am not exactly sure why root would have to read the
manpages in /root/man at all.
Why not using /tmp/man as the place for such manpages and
thus letting all users on the system participate as long as
it only means _reading_the manpages from there.
Yes, I am _perfectly_ fine with the concept of not dealing
with created /root hidden files as well.
It's very probably really evil and we should close all doors
for wrongdoers.
Or if you think /tmp is problematic why not having root
create these pages in the default nonroot user grml's place
~grml/man as well.
Or why not having root to use the grml user for even all
manpages reading and not dealing with root for a reason
here.

> Thanks for the 'lzop -U' hint, it's online:
> http://hg.grml.org/grml-scripts/rev/11dfd9644744

thanks for catching the ball so many times and making
something that fabulous out of a great idea!

        kudos,
                Maddi aka wuehlmaus
msg39 (view) Author: mika Date: 2006-11-26.16:23:52
Shipping ~/man/zshall.txt.lzo is not an option, for example user root would 
never get that. So if we want to change manzsh we must find another way...

Thanks for the 'lzop -U' hint, it's online:
http://hg.grml.org/grml-scripts/rev/11dfd9644744
msg37 (view) Author: maddi Date: 2006-11-26.15:16:28
ouch! yes, that was a bad formulation once more. What I meant was the mechanism
more than an actual fma call.
manzsh is nice because it makes finding certain zsh items nicer
than default fma $manpage_name.
Would it be too costly to provide zshall as an already provided ~/man/zshall.txt.lzo
and then use the regex-power of vim to search for everything for instant access?
e.g.
manzsh() 
         {
          vim -S readoptions.vim -c 'set ft=man|set hlsearch' =( lzop -Ucd
~/man/zshall.txt.lzo )
         }       

PS: Just a little reminder, lzop -U is better, because otherwise you have the
uncompressed zshall.txt lying in ~/man, too. lzop is different from gzip, bzip here!
msg31 (view) Author: mika Date: 2006-11-26.10:38:38
I though about it as well. But currently we have:

manzsh () {
        /usr/bin/man zshall | vim -c "se ft=man| se hlsearch" +/"$1" -
}

so the '$1' stuff will be lost using fma, right?

thx,
-mika-
msg29 (view) Author: maddi Date: 2006-11-26.08:05:25
manzsh should by all means use fma for faster access of this huge manpage
History
Date User Action Args
2006-12-02 18:00:04mikasetstatus: in-progress -> resolved
messages: + msg72
title: manzsh should be using fma -> Upload Close
2006-12-01 06:57:25matthisetmessages: + msg58
2006-11-29 20:56:24mikasetmessages: + msg54
2006-11-29 16:37:35maddisetmessages: + msg53
2006-11-28 11:11:05mikasetpriority: urgent -> wish
2006-11-26 16:23:52mikasetnosy: + mika
messages: + msg39
2006-11-26 15:16:28maddisetfiles: + readoptions.vim
messages: + msg37
2006-11-26 10:38:38mikasetmessages: + msg31
2006-11-26 08:05:25maddisettopic: + zsh, - just ideas
messages: + msg29
2006-11-26 08:03:20maddisetmessages: - msg28
2006-11-26 08:02:09maddicreate