The keyboard of [EMAIL PROTECTED] emitted at some point in time:
>
>
>
> One of the reasons to use setuid was to prevent users from manipulating
> data in any way other than a certain application.
And it is probably the worst. Slapping setuid onto executeables so that
they can manipulate global files is easily the biggest single source of
security breaks.
> I want a particular executable to be the only route a user has
> to access a set of files.
Set up a server to do this, and make it listen on a port. (I guess you
are using some kind of network, as otherwise you would not have a
problem with afs.) Devise a set of request messages, provide a library
of routines constructing them, and link people's applications against
that. This gives you immediately the following benefits:
o Your application will scale immediately to reasonably big databases.
o You do not need to provide new code for every new fashion in user-
interface design.
o You can upgrade your database processing independently of any
upgrade in the programs the requestors use, or their underlying
operating systems.
The fact that some 13 years ago Sun cloaked a message passing system in
terms of procedure calls (rpc) does not mean that you are never allowed
to think in terms of message passing rather than procedure calls.
Thomas
* email: cmaae47 @ imperial.ac.uk (uk.ac.imperial on Janet)
* voice: +44 171 594 6904 (day)
* fax: +44 171 594 6958
* snail: Thomas Sippel - Dau
* Application Support Group
* The Center for Computing Services
* Imperial College of Science, Technology and Medicine
* Exhibition Road
* Kensington SW7 2BX
* Great Britain
