Link to home
Start Free TrialLog in
Avatar of raza
razaFlag for United States of America

asked on

how to allow read not copy

I have a network of Solaris 2.8 on sun sparc machines. HOw do I setup a restriction that allow users to read but not copy.
Is there any CP command that I need to replace for that?

Any Idea?

Avatar of interiot
interiot

In general, you won't be able to do this unless it's a very very restrictive environment.  In general, reading implies copying (something the RIAA doesn't seem to understand).

For instance, the following are equivalent
    cp a /tmp/a
    cat a > /tmp/a
    head -999999 a > /tmp/a
    less a
        (type "l", then "/tmp/a")

Avatar of raza

ASKER

HOw do I setup this very very restictive environment?
It takes a lot of effort to be thorough, especially if you're starting off with an environment that's supposed to be open and trying to change it to be very restrictive.

Do the users require shell access, or can you restrict them to only a menu of specific commands that you've authorized as okay?
simple answer: IMPOSSIBLE

Proove: assuming it's text file which I can view with cat,
then I simply redirect output to a file of my choice. Ready.
Not impossible.  Just mount filesystems read-only and/or set file permissions so no files can be created/modified.

Also makes the system useless.
chris_calabrese, should we discuss about the definition of "impossible"?
Even if the user just has a diskless client, and no write permissions at all anywhere. If it is a text file and can be read (displayed on monitor), who do you restrict to use a webcam and OCR software on another (full accessable:) host?

I agree, if the system is made useless, it's copy protected
;-)
oops, forgot to say that "useless" is a synonym for "unaccessable" (or unreadable in this case)
Am I missing something here?

why not setup a restricted Korn Shell (rksh)
and put a shell scripted version of the copy command

ie

#!/bin/sh
CMDS=${0}
ARGS=${*}
echo "$CMDS $ARGS"
/bin/real_copy_command ${ARGS}

If you wanted to get really tricky you could revoke execute access from the target command (ie a copy of copy), and rewrite the above as a compiled setuid C program.

(The above - even without the rksh - is similar to the function of a "rootkit", and is often used to hide processes, files and other items from a sysadmin.)
festive, like ahoffmann said there more ways to copy than cp.

Just think of cpio, tar, and other backup programs. You have redirection, piping, you can use cut/paste, you can email data, ... You can use printscreens...
If your station doesn't have a diskette drive, just open a terminal on another persons display ...

So make it impossible for someone to 'steal' content while give them read access is IMHO 'impossible'.
ASKER CERTIFIED SOLUTION
Avatar of festive
festive

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Part answer

OK in general it is imposable unless control every thing a user can do. See above

Except if it is a binary executable. (May work with scripts)
chmod 511 File

The OS can now exec it but a user can not read it.

I must ask why you want to submit your fellow humans to this pain. have a look at www.gnu.org to font out why not to do it.
chmod 511 is useless.
If a user cannot read a file it cannot be executed, for obvious reason.

raza, are you still listening?
Avatar of raza

ASKER

Yes, I am here
511 is not useless
I have used it.
on a directory it will not apear in a listing but you can traverce it. (secret directorys, not very secure)

on a binary you can execure it but not read it, Did not work for scripts as for these you do have to read them the execure bit is not used by the OS/kernal but by the shell, and the shell must read it.

Dont know the POSIX standard for this but solaris about 8 years ago did it this way.

Try it
> on a binary you can execure it but not read it, Did not work for scripts

I aggree ;-)
Thanks raza,

I Hope it all works well - sounds very interesting!


Festive