Subject: Races

From: Marc SCHAEFER <[email-masked]>
Date: Thu, 4 Sep 2008 11:01:51 +0200

Hi,

*IF* POSIX or general use mandates that chmod(2) should not change
ctime if no change really occurs, this should be fixed in the
Linux kernel itself.

Fixing it in user space in the chmod(1) utility is wrong, because it
could introduce user-space race conditions.

For example:
   timestamp 1: perm is 0500
   timestamp 2: perm is 0700
   timestamp 3: perm is 0500

we would expect c_time to be timestamp 3 at the end of this flow.

Now imagine that you have two processes. Process one wants to set
perm to 0500, process 2 to 0700.  Imagine it works as follows:

   process 1                      process 2
   stats file, gets perm 500
                                  stats files, get perm 0500
                                  set permissions to 0700, ctime changes

   set perm, no real change,
   so don't do anything

WRONG! permission is 0700!

(one could argue that the overall result is undefined if the two
processes are scheduled in parallel anyway; however there seem to be
something wrong in the user-space semantic here anyway)

(in general, any "I check manually, then I set" method is wrong,
 unless it is done atomically, which is not the case for user space
 and can only be guaranteed with kernel locks with currently used
 Linux kernels)

---

From: Jim Meyering <[email-masked]>
Date: Thu, 04 Sep 2008 13:36:54 +0200

Marc SCHAEFER <[email-masked]> wrote:
> ctime if no change really occurs,

Neither mandates that.