Very Computer

You could store the files under a different ownership. None of those files
permission masks would allow world and group access. Only through the program
would access be possible. Of course this idea depends on whether your pro-
gram has super-user priviledges. If the program were invoked from your login
it'd need to setuid() the owner of the files in order to manipulate them.

Jeff

I have been making a program that acts like a simple filemanager, moving certain files
around and stuff like that. One of the operations of the program is to store a file in
a write-protected directory, and not allowing the normal user to access the file without
using the program.
Is it possible to solve this problem using some protection-bits, or do I have to code it
into my program? In case of coding, how should I solve the problem?

Thanks in advance

***************************************************************************
* Jonas Ahlstrom                            *"Let us have wine and women, *
* Barytongatan 6                            * mirth and laughter, sermons *
* S-421 38 V:a Frolunda, Sweden             * and sodawater the day after"*
* Phone: +46-(0)31-470817                   *                             *

* WWW:http://www.dtek.chalmers.se/~d0ahljo  *                             *
***************************************************************************

When I came accross that problem thats effectively what I did. The program
run by the user calls a setuid program with argv[0] set to a certain special
string so as to prevent a user running the setuid program directly.
The setuid program could only move, copy or delete certain files so security
in the unlikely event that a user had found the magic argv[0] and called it
was not too much a problem. One thing to watch out for security wise is what
programs your setuid prog calls. If you issue a command like "mv file1 file2"
then all a user need do is put their own version of mv in their path.
I'm sure that there are C libraries to do this. At the time I just made sure
I called /bin/mv .
Another method reccomended to me at the time would have been to use UNIX (not
INET) sockets and run the copying/moving program completely indipendantly.

- Richard

please excuse spelling. With the current load on this computer I'm not going
to run ispell!

--
   _/_/_/   _/_/_/   _/_/_/   Richard Corfield. St John's, Cambridge

 _/_/_/     _/   _/           World Wide Web: http://club.eng.cam.ac.uk/~93rjc
_/    _/ _/_/     _/_/_/      Disclaimer: My opinions are MINE! ALL MINE!

Something you could do is create a mode 777 directory inside a mode 700
directory (owned by you, the privileged user).  Then make a setuid
program which chdir's into the writable directory, then resets the
uid/gid and runs the real program.

This way, the program starts up in a directory which it can write
into.  No other programs can reach that directory because they don't
have execute permission for its parent.

Downsides: the current directory gets changed.  Maybe the parent could
save it and pass it as an environment variable or something.  If the
program does a subsequent chdir, you lose access to the protected
directory.  You have to make sure the user doesn't direct the file
manager to access the protected directory in a sneaky way.

In general, Unix-domain sockets are the way to go (as someone else
suggested).  Put the socket in a directory only you can execute,
connect to it in a setuid wrapper, reset [ug]id, and go.  You'll need
to start a server if it isn't running, of course.

Probably the most Unix-clean way to do it is to have a setuid program
which will perform all possible valid operations on the secret data.
This means moving all the security stuff out of your main code,
however.

 --adrian.

--

Student Computing Research Group, Trinity College, Dublin (Ireland!)
<URL:http://www.scrg.cs.tcd.ie/u/aecolley> OID: 1.3.6.1.4.1.1201.1.1
phones: work=+353-1-6769089; fax=+353-1-6767984; home=+353-1-6606239