On Mon, 2 Jun 2003, Sandra Hernandez wrote:
> I'll try to resume what I have tested..
> First of all, a brief description of the problem: I want to make the
> file mbox undeletable for users (but users still can remove,add,modify
> data in file), and this file is into $HOME/nsmail directory.
I suspect you want more than that, specifically, you probably want
existing mail clients to be able to modify the file in the method
they currently use, which may involve steps like these when
deleting messages:
open existing
read from existing file
rename existing file to temp
open new file with old name
write to new file
close new file
close renamed file
unlink renamed file
If that is the case then you have conflicting desires, because you
want to prevent the user from deleting their own files, but you want
to allow the mail client to unlink the file.
This looks like a user education problem, and sounds like you are
trying to keep the users from shooting themselves in the foot,
presumably by misuse of rm.
Restricting access to the system unlink() function without breaking
anything will be difficult.
Assuming you've already found `alias rm='rm -i'` insufficient, have
you considered replacing /bin/rm with a script that refused to remove
particular files?
Coddling users by restricting access to /bin/rm, or replacing it with
a script that refuses to remove particular files seems managable, if
it is misuse of /bin/rm that concerns you, and not misuse of unlink().
