Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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).

share|improve this question
    
Check out the SGID bit option of chmod (in johnathan's answer below). This will save you from having to set the group with a cron. –  Chris Nava Sep 22 '09 at 21:48
1  
@Chris: I do know about it. But I need something which fixes moved files too. –  Deleted Sep 22 '09 at 22:02

3 Answers 3

up vote 7 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
Yes, I've been leaning towards this too. Do you know any source where I can read more about this? I would like to know if this is portable between all unices. If it's part of the POSIX standard. –  Deleted Sep 22 '09 at 22:01
    
I'm afraid I don't know.. :( Maybe someone on ServerFault would? I think that'd be a better "audience" for a question like this.. –  Joril Sep 23 '09 at 12:50

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.

share|improve this answer
    
I do know about the SGID-bit and I'm using it. But it doesn't work for files I've created somewhere else which are then moved to /home/shared, which the cron-job takes care of. But it was nice trivia and interesting to learn the difference on MacOS X. –  Deleted Sep 22 '09 at 21:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.