CODEWITHSUNDEEP
perlpermissions
Jacob Wegelin
Jacob Wegelin

Reputation: 1306

Can I prevent a Perl program from modifying any file?

I write scripts in Perl 5.18 and in bash, under BSD unix, on a MacBook Pro.

The bash command set -o noclobber will globally protect me from inadvertently replacing any file by use of cat, even if I have write permission. But as we see below, it does not prevent me from modifying that file.

> find z
find: z: No such file or directory
> set -o noclobber
> echo DOG > z
> ls -lT z
-rw-r--r--  1 BNW  staff  4 Jun 19 10:36:05 2020 z
> echo DOG > z
-bash: z: cannot overwrite existing file
> ls -lT z
-rw-r--r--  1 BNW  staff  4 Jun 19 10:36:05 2020 z
> echo DOG >> z
> ls -lT z
-rw-r--r--  1 BNW  staff  8 Jun 19 10:36:28 2020 z
> cat z
DOG
DOG
> perl -pi -e 'use strict; use warnings; s/D/W/g; ' z
> ls -lT z
-rw-r--r--  1 BNW  staff  8 Jun 19 10:59:16 2020 z
> cat z
WOG
WOG

Is there a global setting that one can place inside a particular script, either bash or perl, something like set -o notouch, that will similarly prevent that script from inadvertently modifying any file at all? I do not want to change the permissions on the file; I want a "safety switch" at the very top of my script, to prevent the script from making any changes. I want to handcuff my script so that all it can do is look, like Alex in A Clockwork Orange. I want my script to have read permission but no other permission.

The script searches through the contents of thousands of files. Although I have write permission, the files must not be "touch"-ed or changed in any way other than the unavoidable updating of their access time (atime). Their permissions must not be changed. Their modification time (mtime) and ctime must remain constant and, of course, their contents must not be changed --- not by appending, for instance, not by sed or by perl.

It would be possible inside a script to change the permissions on each file and then change the permissions back after one has looked at it. But this would change the status-modification time (ctime), as we see here:

> /bin/rm z
> touch -t198001010000.13 z; # create file with mendacious mtime
> stat z
16777220 8696665084 -rw-r--r-- 1 BNW staff 0 0 "Jan  1 00:00:13 1980" "Jan  1 00:00:13 1980" "Jun 20 16:50:24 2020" "Jan  1 00:00:13 1980" 4096 0 0 z
> grep DOG z; # change atime to right now
> stat z
16777220 8696665084 -rw-r--r-- 1 BNW staff 0 0 "Jun 20 16:50:47 2020" "Jan  1 00:00:13 1980" "Jun 20 16:50:24 2020" "Jan  1 00:00:13 1980" 4096 0 0 z
> # note the ctime (3rd date in stat) equals the time the file was created. Now change permissions.
> chmod a-w z; chmod a-x z; # this will change the ctime
> stat z
16777220 8696665084 -r--r--r-- 1 BNW staff 0 0 "Jun 20 16:50:47 2020" "Jan  1 00:00:13 1980" "Jun 20 16:52:02 2020" "Jan  1 00:00:13 1980" 4096 0 0 z
> # That behavior is unacceptable. It destroys valuable information about the file.

Without changing the permissions on files, is there a "switch" or setting that will prevent a particular script from doing any of the forbidden things to a file?

Upvotes: 1

Views: 135

Answers (1)

brian d foy
brian d foy

Reputation: 132857

noclobber doesn't do what you think it does. Here's it seemingly protecting with perl. It prevent shell redirection from overwriting files and doesn't care which program produced the output:

$ set -o noclobber
$ more test.txt
one
two
three
$ perl -e 'print "replaced"' > test.txt
-bash: test.txt: cannot overwrite existing file

Imagine if such a switch existed. Do you want to rely on it for everything to work? You set it, but something unsets it, such as a buggy, failed, or incomplete deployment. It was a bit of duct tape to start with. Then, once set, how do you modify files? You turn it off, and forget to reset it.

Various systems have file permissions or access control lists (ACLs). If you are worried about a program doing something you don't like, run it in a different environment. This is why many tools has dedicated user accounts.

But, consider if you really want to use the filesystem metadata as your database. If it's actually that important, it's worth tracking the interesting information in something that you can completely control. Trying to work around the normal operations on the filesystem is a recipe for pain and suffering. You mention A Clockwork Orange, but the scheme in that movie drove its patient to suicide.

Upvotes: 1

Related Questions