Truly read-only viewer like more or vi?

[A. Daniel King_1]

Hi, folks -

Do any of you know of a read-only editor like vi/less/more/rvim/rvi? I guess I don't want an editor at all, but a secure ascii file viewer - without shell escapes or command execution - that otherwise acts like vi. I've been over a few items, but I've found problems with each:

> rview allows saves with a !, i.e., "wq!"
> more allows calling vi (or other editor) with 'v'.
> less ditto.
> Various options on vim including -Z -R, etc. still allow saving files with "wq!"
> pg -r behaves differently than vi (learning curve for my users).

Any ideas are greatly appreciated. HP-UX-only ideas supremely appreciated.

[MANOJ SRIVASTAVA]

Hi Daniel


Did you try view , man view .


Manoj Srivastava

[A. Daniel King_1]

view allows "wq!" - and shell escapes.

As part of the charityware package vim, there are rvim and rview, which cut off the shell escapes:

:shell
:!ksh

However, I can still do:

:w!

And overwrite files.

[Paula J Frazer-Campbell]

Hi

What about cat | more ??


Paula

[S.K. Chan]

Take a look at "mas" from the HPUX porting center. I remembered using it at one point in time. It's relatively simple and the way to run it is just "./mas filename". It brings up X and you have capbility to search within the viewer. I think it does not allow you to modify and save the file (so strictly viewing).

http://hpux.cs.utah.edu/hppd/hpux/Editors/mas-1.0/

[Jeff Schussele]

Or just
more /path/to/filename
all by itself.
You can search w/more - just use the "/" as you would in vi as well as go to line numbers using "G".

Jeff

[A. Daniel King_1]

more in the case of 'cat x | more' does prevent file overwriting. This is good.

However, I can still do:

!ksh

I will look at mas. Does it look like vi?

[A. Daniel King_1]

more in the case of 'more x' ...

Try pressing the 'v' key while viewing a file with more. This throws you into your editor - vi typically. This is not the desired behavior.

[A. Daniel King_1]

mas is for GUIs. I neglected to mention that the system I'm on is almost completely terminal based.

[S.K. Chan]

Looks like a regular hpterm/xterm window and all it has for it's menu bar (on top) are ..
- find (to find a certain text match)
- find same (not sure what's this)
- copy (presumbly allows you to copy text from this viewer to another window or editor)
- quit
- about
There is no other options for save/edit/cut/paste. It allows you to scroll the window text.

[James R. Ferguson]

Hi Daniel:

If you want to defeat the shell escape, you could create a wrapper for 'vi' for your users that sets the SHELL variable to null, exports it and then invokes 'vi':

#/usr/bin/sh
export SHELL=
vi $1
exit 0
#.end

Regards!

...JRF...

[Jeff Schussele]

Daniel,

Yep, you're right.
I was not aware of that.
Learned something new today.

A point I would make is that even *if* you find a suitable candidate, there is no substitute for proper dir/file perms. The user can still do
> filename
& poof it's zeroed.
You can keep them out of shells, but it sounds like you don't.
Definitely attack this on both fronts.

Rgds,
Jeff

[MANOJ SRIVASTAVA]

Hi Daniel


What about strings filename | more


Manoj Srivastava

[Paula J Frazer-Campbell]

Hi

Instead of them viewing the file let them view a copy of it which is discarded afterwards.

so they see:-

view xyz

But in the background:-


cp xyz /tmp/tmpxyz
more /tmp/tmpxyz
rm /tmp/tmpxyz


Just an idea

Paula

[A. Daniel King_1]

Jeff, you are correct - there is no substitute for correct permissions. However, consider the following scenario:

I've got a SUID root program that allows a particular set of users to 'view' a file - otherwise unviewable. I don't want them to be able to change the file, nor escape to a shell.

James, I wish there were a rating for coolness. The null SHELL wrapper is a very good idea. THANK YOU!!! This gets me half-way there.

Now, I can reduce the question to:

Is there an editor which does not allow overwriting with "w!"? I think that this has been covered with the 'cat x | more'.

So, I try a script like:

#!/usr/bin/ksh

cat $1 | SHELL="/dev/null" /usr/bin/more

and I have the results:

'v' produces: "Cannot edit standard input (press RETURN)"

'!ksh' produces: "sh: /dev/null: Execute permission denied."

And I am happy, unless I'm missing some other escape from more. 10 points to whomever has an alternate suggestion or can quantify the answer more concisely!

[Vincent Fleming]

I can't think of anything like what you're looking for either... but...

You could always get the source code to 'vi' from a Linux or FreeBSD system (it's downloadable for free), and modify it to disallow saving, shell escapes, etc.

It would be some work, but it might not be as bad as you think. I've done things like that a lot.

Good luck!

[Paula J Frazer-Campbell]

Hi

Another option, but will only work on files that are satatic.

When a user selects to view a file by whatever method then take away its write capability:-


So if file is normally :-

-rwxrwxrwx 1 root sys 4492 Dec 15 2000 vm2

As it is selected to view chmod it to:-

-r-xr-xr-x 1 root sys 4492 Dec 15 2000 vm2

And restore it on their exit.


Paula

[Tim D Fulford]

If the files are static you could always mount them on a read-only filesystem. This sounds weird but we had a read-only database and mounted the data as above.

Ive even activated whole volume groups as read-only (vgchange -a r ) for sanity checks & stuff.

just a thought

Tim

[A. Daniel King_1]

Paula,

Changing the rights on the file is easily overcome with "w!".

Tim,

Though interesting, the mount solution is highly impractical.

Thanks for the replies.

[Volker Borowski]

Hi,
well I think you nearly have everything found you need.
To "more" from a pipe is quite safe, esp. if "vi" is not call-able at all, because it can not read from a pipe.

A point you might keep in mind is that the real problem with "vi" in a suid-root script might not be
:wq!
but
:w/dev/rdsk/c....! -- DO NOT TEST THIS !!!

You should consider a cronjob or some other kind of interface, that "chown"s this file you like to give away to seperate non-root account and call your script with a special suid-accessuser.

Play it safe
Volker

[Martin Johnson]

Have you tried using the restricted shells? rsh or rksh?


Marty

[Keith Buck]

Can you add all the users to a group and make the file group-readable (but not writeable)? This avoids the need and allows the users to use their choice of editors. (still owned by root so :wq! doesn't work)

If you have to do an SUID program

1. don't make it SUID root...there are too many things which can go wrong

2. simply use the SUID script to copy the file into a temporary location (make sure that it is hardcoded to prevent overwriting other files as the non-root SUID user...the user running this thing controls environment variables) Also make sure that the filenames you are reading are checked explicitly (don't use $1, it could contain a lot of things you don't want)

3. run the cat $1 | more as the real user, not the SUID user. There are a lot of things that more can do that you don't want happening as root or anyone other than the user themselves. (including :w, :e, and !, even
with SHELL=/dev/null)

4. You can improve the safety of your SUID program if you write it in Perl and use the -T option. (will force you to clean environment variables, etc. before using them)

You can also make your SUID non-root program executable only by the group of users who need it (rather than world-executeable).

Hope that helps...I think I may have just made it harder :( but those are all things you need to consider before making an SUID program.

[Frank Slootweg · Accepted solution]

I think your

#!/usr/bin/ksh
cat $1 | SHELL="/dev/null" /usr/bin/more

method is probably best. I don't know of any holes in that approach.

Not that you intend to, but you can not use the "SHELL=...." trick with vi(1), because one can use ":set shell=...." to undo the trick.

[James R. Ferguson]

Hi Frank:

Thanks for pointing out the flaw in my SHELL logic when 'vi' is invoked! I hadn't considered that (obviously).

/no points please/

Regards!

...JRF...

[Steven Sim Kok Leong]

Hi,

If you have lynx installed, you can use the following to read a file:

#lynx -restrictions=all /myfile.read-only

This restricts all lynx functions, including ! (shell spawning). Among the few options you can access are "help", "print", "search" and "quit". The rest are mostly disabled.

Hope this helps. Regards.

Steven Sim Kok Leong