File protection against deletion

File protection against deletion

Post by <K.. » Tue, 30 Mar 1993 23:13:08



Hi :
         I have two questions:
1. Is it possible to protect a file in a unix environment. The options
   available with chmod command does only prevent the file being
   overwritten. I have "found" one way to do this by changing the owner
   to root for the file AND the directory in which the file is. But this
   makes life more difficult for things like compressing the file.
   What I am looking for is something similar to the write protect command
   in VMS which will give a "permission denied".

2. Is it possible use a magnetic tape to write an output file directly
   from a program by assigning the device ?

K.V. Damodaran
PennState University
Chem. Department


 
 
 

File protection against deletion

Post by Joshua A. La » Wed, 31 Mar 1993 22:00:05


:)1. Is it possible to protect a file in a unix environment. The options

"chmod 400 <filename>" (use 500 if it's an executable file) will make the file
non-writable to the owner. When the owner tries to remove this file, (s)he
will get the following message:
rm: override protection 400 for <filename>?

Upon which one can say "n".

--
 Joshua A. Laff, CRL operator, UofI          (217) 384-6249

_______________________________________________________________________________
Disclaimer: If I were speaking for the UofI, I wouldn't be paying tuition.

 
 
 

File protection against deletion

Post by der Mou » Thu, 01 Apr 1993 21:14:26



> 1. Is it possible to protect a file in a unix environment [against
>    deletion].

Maybe.  What type of deletion do you wish to protect against, and what
lengths are you willing to go to?

If write permission is denied on a file, then most versions of rm will
normally ask for confirmation before removing it.  You may be able to
simply remove write permission.

If you wish to cause unlink() syscalls to fail, nothing you do to the
file itself will work.  All unlink() requires is write access to the
directory the name being unlinked appears in.

UNIX does not have a separate delete permission bit, at least partly
because deletion is not an operation on a file; it is an operation on a
file *name*.  Files themselves are deleted implicitly as soon as they
become unreferenceable.  Since the permission bits are attached to
files, not names, a delete permission bit doesn't make as much sense as
it might at first appear.

This actually brings up a subtle point: do you want to protect the name
or the file itself?  If the latter, you an simply keep a (hard) link to
it in another directory that only you can access.

Quote:> 2. Is it possible use a magnetic tape to write an output file
>    directly from a program by assigning the device ?

I'm not sure what you mean.  Since you earlier mentioned VMS, I assume
you are looking for something like the VMS ASSIGN command.  UNIX does
not have anything directly comparable, though symbolic links can serve
in some circumstances.  What you would normally do in UNIX is provide
the appropriate name in /dev as the output filename; this would
correspond to, in VMS, giving something such as MTA0: as the output
filename for a program.

                                        der Mouse


 
 
 

File protection against deletion

Post by JOHN STOK » Fri, 02 Apr 1993 06:03:49




>Subject: Re: File protection against deletion
>Date: Wed, 31 Mar 93 12:14:26 GMT

>> 1. Is it possible to protect a file in a unix environment [against
>>    deletion].
>UNIX does not have a separate delete permission bit, at least partly
>because deletion is not an operation on a file; it is an operation on a
>file *name*.  Files themselves are deleted implicitly as soon as they
>become unreferenceable.  Since the permission bits are attached to
>files, not names, a delete permission bit doesn't make as much sense as
>it might at first appear.

If this is the case, then  it should be possible to recover a lost file. I
remember some discussion on this before but the solution was a hack at
best. (using fsck & fsdb to find the proper i-node, etc i think)  I for one
haven't ever heard of a program to "undelete" a file but if Peter Norton
can do it, and become rich & semi famous for it, maybe some adventorus
programmers could give it a whack.  I know little about file structures or
I'd start such a beast.  Maybe we could pay Dr. Norton himself.... NAH!!
                                                                -John
--------------------------------------------------------------------------------
John W. Stokes, Jr., Triangle Fraternity (Lou '91), University of Louisville


Disclaimer:  The opinions stated above are personal opinions, and in no way
             reflect the opinions of any other entity, unless otherwise stated.
------------------------------>Don't Flame, EXPLAIN!<---------------------------
 
 
 

File protection against deletion

Post by Danny R. Faug » Sat, 03 Apr 1993 07:56:44





>>> 1. Is it possible to protect a file in a unix environment [against
>>>    deletion].

>>UNIX does not have a separate delete permission bit, at least partly
>>because deletion is not an operation on a file; it is an operation on a
>>file *name*.  Files themselves are deleted implicitly as soon as they
>>become unreferenceable.  Since the permission bits are attached to
>>files, not names, a delete permission bit doesn't make as much sense as
>>it might at first appear.

See how your system handles the sticky bit on directories.  Try man 8 sticky
or man 2 chmod.  Depending on your system, this may allow you to give people
permission to write to a directory, but not to delete arbitrary files.  They
probably will still be able to delete files that they own, however.

Quote:>If this is the case, then  it should be possible to recover a lost file. I
>remember some discussion on this before but the solution was a hack at
>best. (using fsck & fsdb to find the proper i-node, etc i think)  I for one
>haven't ever heard of a program to "undelete" a file but if Peter Norton
>can do it, and become rich & semi famous for it, maybe some adventorus
>programmers could give it a whack.  I know little about file structures or
>I'd start such a beast.  Maybe we could pay Dr. Norton himself.... NAH!!

I don't know the*details, but I've heard it's virtually impossible to
recover a file on a Unix timesharing system because as soon as you delete the
file, someone else's file will overwrite that portion of the disk.
--
Danny Faught, Convex rookie
"Everything is deeply intertwingled." (Ted Nelson)
 
 
 

File protection against deletion

Post by der Mou » Sun, 04 Apr 1993 01:13:45





>>> 1. Is it possible to protect a file in a unix environment [against
>>>    deletion].
>> UNIX does not have a separate delete permission bit [...] deletion
>> is not an operation on a file; it is an operation on a file *name*.
>> Files themselves are deleted implicitly as soon as they become
>> unreferenceable.  [P]ermission bits are attached to files, not
>> names, [...]
> If this is the case, then it should be possible to recover a lost
> file.

Why do you think that, and what do you mean by "lost" here?

Quote:> I for one haven't ever heard of a program to "undelete" a file but if
> Peter Norton can do it, and become rich & semi famous for it, maybe
> some adventorus programmers could give it a whack.

If you're on a single-user bitty box with a rudimentary filesystem
format, the problem becomes *much* easier.  I once looked at doing a
syscall to recover unlinked files on a Berkeley system with the
Berkeley filesystem, and found it would be a major pain: the code would
have to be rewritten to keep around block pointers past EOF, or else
would have to free space differently when removing an inode.

There are products that provide some degree of undeletion for UNIXish
systems, but as far as I know they all work by moving "deleted" files
into a holding area.  (If such a thing were done in the kernel, it
would even be possible to have the holding area cleaned out
automatically as necessary to make room for new files, which is the
major problem with doing it otherwise: "deleted" files continue to
occupy disk space.)

                                        der Mouse