On Sun, 8 Jul 2007, Linus Torvalds wrote:
> 
> No.
> 
> notify_change() does *not* do permission checks for 
> ATTR_CTIME/MTIME/ATIME.
> 
> It does them for the "xxx_SET" attributes, but MTIME/ATIME is expected to 
> change when other things change, so notify_change() expects that those 
> _other_ changes have been validated from a security standpoint!
> 
> utimes() is special.

This might be an acceptable patch.

Al? What do you think? Basically, it says that

 - the file owner can always set MTIME/ATIME, of course

 - non-owners can set it only when they have write permissions, and if it 
   was a file descriptor, the only way for us to know that they have write 
   permissions is if it's opened writably, which is hopefully equivalent 
   to that MAY_WRITE test (except the MAY_WRITE test was done at _open_ 
   time).

This would seem to be the minimal change, and I think it's right.

                Linus

---
 fs/utimes.c |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/fs/utimes.c b/fs/utimes.c
index 480f7c8..b3c8895 100644
--- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -106,9 +106,16 @@ long do_utimes(int dfd, char __user *filename, struct 
timespec *times, int flags
                 if (IS_IMMUTABLE(inode))
                         goto dput_and_out;
 
-               if (current->fsuid != inode->i_uid &&
-                   (error = vfs_permission(&nd, MAY_WRITE)) != 0)
-                       goto dput_and_out;
+               if (current->fsuid != inode->i_uid) {
+                       if (f) {
+                               if (!(f->f_mode & FMODE_WRITE))
+                                       goto dput_and_out;
+                       } else {
+                               error = vfs_permission(&nd, MAY_WRITE);
+                               if (error)
+                                       goto dput_and_out;
+                       }
+               }
        }
        mutex_lock(&inode->i_mutex);
        error = notify_change(dentry, &newattrs);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to