don't allow utime()/utimes() on immutable/append-only files

don't allow utime()/utimes() on immutable/append-only files

Post by Ethan Benso » Mon, 09 Jun 2003 08:20:14



Hi,

I recently noticed that utime() and utimes() is allowed on immutable
or append-only files.  I believe this should not be permitted.

Attached is a patch which returns -EPERM on attempts to set timestamps
explicitly (utime[s]() with a timebuf arg), and which returns EACCES
when these are called with a NULL time arg for immutable files.

utime/utimes with a NULL time arg is allowed on an append-only file.
Since timestamps are updated when append-only files are written to, it
seems acceptable to allow the timestamp to be updated to the current
time.

I am not subscribed to linux-kernel, so please CC any replies, thanks.

--- linux.orig/fs/open.c        Sun Jun  1 20:39:38 2003

        /* Don't worry, the checks are done in inode_change_ok() */
        newattrs.ia_valid = ATTR_CTIME | ATTR_MTIME | ATTR_ATIME;
        if (times) {
+               error = -EPERM;
+               if (IS_APPEND(inode) || IS_IMMUTABLE(inode))
+                       goto dput_and_out;
                error = get_user(newattrs.ia_atime, &times->actime);
                if (!error)

                newattrs.ia_valid |= ATTR_ATIME_SET | ATTR_MTIME_SET;
        } else {
+               error = -EACCES;
+               if (IS_IMMUTABLE(inode))
+                       goto dput_and_out;
                if (current->fsuid != inode->i_uid &&
                    (error = permission(inode,MAY_WRITE)) != 0)

        newattrs.ia_valid = ATTR_CTIME | ATTR_MTIME | ATTR_ATIME;
        if (utimes) {
                struct timeval times[2];
+               error = -EPERM;
+               if (IS_APPEND(inode) || IS_IMMUTABLE(inode))
+                       goto dput_and_out;
                error = -EFAULT;
                if (copy_from_user(&times, utimes, sizeof(times)))

                newattrs.ia_mtime = times[1].tv_sec;
                newattrs.ia_valid |= ATTR_ATIME_SET | ATTR_MTIME_SET;
        } else {
+               error = -EACCES;
+               if (IS_IMMUTABLE(inode))
+                       goto dput_and_out;
+
                if (current->fsuid != inode->i_uid &&
                    (error = permission(inode,MAY_WRITE)) != 0)
                        goto dput_and_out;

--
Ethan Benson
http://www.alaska.net/~erbenson/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. utime vs utimes

My application is sort of a backup program. It stores a file's contents
in a database along with its metadata (owner/mode/mtime/etc) on a server
machine. At some later time, if needed, the file is restored to its
original state.

I've realized the current implementation is throwing away any sub-second
resolution in the last-modified time. Some platforms store both seconds
and microseconds (or nanoseconds in the case of Solaris), but the
st_mtime member retrieved by stat() only has the seconds part.

So I'm looking for two things: (1) the most portable/standard way of
getting the micro/nano second part from the stat structure and (2) the
best way to set that metadata back onto the newly restored file.

For the 'get' part, it looks like there's no standard API. Looks like a
bunch of ugly ifdefs are required. Does anyone have a sample piece of
code that handles the major platforms or just shows the way?

The 'set' part raises a question about the intention of SUS. The utime()
function is in the standard but is explicitly limited to seconds (SUSv3:
"The times in the structure utimbuf are measured in seconds since the
Epoch."). The utimes() function is also in SUS and allows microsecond
resolution ("The times in the timeval structure are measured in seconds
and microseconds since the Epoch"), but this interface is marked LEGACY
with a usage note indicating "For applications portability, the utime()
function should be used instead of utimes()". I don't get it - why would
the more capable interface be retired in favor of a dumber one? Is there
a non-legacy interface that supersedes utimes() and support setting
sub-second timestamps?

--
Thanks,
M.Biswas

2. [PATCH] IDE clean 12 3rd attempt

3. utime & utimes & POSIX & portability

4. Should I make a change?

5. Where is 'utime' on VAX C?

6. LAN connection to Morningstar PPP

7. How to use 'utime()' on symbolic link?

8. 2.4+ptrace exploit fix breaks root's ability to strace

9. How to change utime of a file

10. file(1) vs utime(3)

11. utime(...) works only with files of owner

12. Finding append only and immutable files

13. Append to files in tar-file but don't change originals.