Change file ownership during write operation

Question

By default the umask is 0022:

usera@cmp$ touch somefile; ls -l
total 0
-rw-r--r-- 1 usera usera 0 2009-09-22 22:30 somefile

The directory /home/shared/ is meant for shared files and should be owned by root and the shared group. Files created here by usern (any user) are automatically owned by the shared group. There is a cron-job taking care of changing owning user and owning group (of any moved files) once per day:

usera@cmp$ cat /etc/cron.daily/sharedscript

#!/bin/bash

chown -R root:shared /home/shared/
chmod -R 770 /home/shared/

I was writing a really large file to the shared directory. It had me (usera) as owning user and the shared group as group owner. During the write operation the cron job was run, and I still had no problem completing the write process.

You see. I thought this would happen:

1. I am writing the file. The file permissions and ownership data for the file looks like this: -rw-r--r-- usera shared
2. The cron job kicks in! The chown line is processed and now the file is owned by the root user and the shared group.
3. As the owning group only has read access to the file I get a file write error! Boom! End of story.

Why did the operation succeed? A link to some kind of reference documentation to back up the reason would be very welcome (as I could use it to study more details).

Answer 1

Afaik, POSIX 1003.1 requires only fopen to return an [EACCES] error on insufficient privileges. Subsequent operations like fputc might return a [EBADF] bad file descriptor error, but i don't think that is meant to cover permission changes while the file is open.

Years ago, i worked in a company where we had our AIX servers set up so that they used that property to make logfiles more secure. When a service started, root would touch /var/log/service.log, then chown it to serveruser:servergroup, su - start the service (it would open the file in append mode), and then chown the file back to root. Consequently, the service could append to its own logfile, but not delete or overwrite it, so if an attacker managed to compromise the service he couldn't tamper with past log entries.

A similar trick can be used for temporary files: open the file, then remove it. The directory entry is gone and the file is invisible, but since the file handle is still open, the inode is still there. Once you close the file, the link count goes to zero, and the OS reclaims the disk space.

Answer 2

I think the reason is that when cron kicks in, you still have a valid handle to the file, so you can use it normally.. In other words, the system checks your rights just when you try to open it, not on every file operation.

Answer 3

As Joril said, the permissions are relevant when the file is opened; they are not checked thereafter.

Remember that you can create a file for writing with 400 (or 444, or 000) permissions on the file. You need permission to create the file in the directory, of course, but you can have write access to a file that no-one else (except root) can modify.

Also note that the group can be set by default by setting the SGID bit on the holding directory:

chmod g+s /home/shared

All files created in the directory will belong to the group that owns /home/shared until the group is changed. On MacOS X, the system behaves as if the SGID bit was set on every directory - when a file is copied to a directory, the group is set to the group that owns the directory.