Protection of tied files

[J Krugman]

Suppose that I have a Perl variable tied to some file. Does Perl
provide any facilities for preventing some other program from
modifying this file, and/or for detecting if such modification
happens? (I'm only interested in the UNIX case).

TIA!

jill

 

[Anno Siegel]

Suppose that I have a Perl variable tied to some file. Does Perl
provide any facilities for preventing some other program from
modifying this file, and/or for detecting if such modification
happens? (I'm only interested in the UNIX case).

That is really a question about Unix then. Perl can only offer services
that are supported by the OS.

The answer is no. There is no way to stop a process with sufficient
permissions to change a file. There may be implementations of mandatory
locking, but that's not standard.

Neither is there a reliable means of checking if the file was changed.
The one-second resolution of file times is too coarse to be sure. The
only way is to keep a copy and compare.

All this is quite independent of the possibility that some Perl program
could have decided to tie a variable (in what sense?) to the file.

The usual solution is to set file permissions so that only collaborating
users (normally just one) have access, and use (advisory) file locking
for access control. That can be made watertight.

Anno

 

[xhoster]

Suppose that I have a Perl variable tied to some file. Does Perl
provide any facilities for preventing some other program from
modifying this file, and/or for detecting if such modification
happens? (I'm only interested in the UNIX case).

TIA!

You could unlink the filename which the variable is tied to, so that the
only remaining link to the file inode is the one held by the perl program.
That should stop all but the most dedicated superusers from messing with
it. This still leaves a brief period in which someone could grab the file,
so to be even safer, you should avoid ever creating the filename entry in
the filesystem in the first place.

perldoc -f open:

As a special case the 3 arg form with a read/write mode and the
third argument being "undef":
open(TMP, "+>", undef) or die ...
opens a filehandle to an anonymous temporary file.

Of course doing this means that the filedata will be lost as soon as your
program exits, so I hope that that is OK with you.

Xho

 

[botfood]

are you asking about flock() considerations to prevent other scripts
from stepping on a tied file, or a permission issue with keeping
network users from touching a file?