linux-kernel - Re: [parch 3/4] vfs: utimensat(): fix error checking for {UTIME_NOW,UTIME

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 4 Jun 2008 11:27:18 +0200
From:	"Michael Kerrisk" <mtk.manpages@...glemail.com>
To:	"Miklos Szeredi" <miklos@...redi.hu>
Cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	hch@....de, viro@...iv.linux.org.uk, jamie@...reable.org,
	drepper@...hat.com, linux-fsdevel@...r.kernel.org,
	subrata@...ux.vnet.ibm.com
Subject: Re: [parch 3/4] vfs: utimensat(): fix error checking for {UTIME_NOW,UTIME_OMIT} case

On Wed, Jun 4, 2008 at 7:12 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
>> > Miklos suggested an alternative idea, migrating the
>> > is_owner_or_cap() checks into fs/attr.c:inode_change_ok() via
>> > the use of an ATTR_OWNER_CHECK flag.  Maybe we could do that
>> > later, but for now I've gone with this version, which is
>> > simpler, and can be more easily read as being correct.
>>
>> Wise decision.
>
> Or maybe not.  Isn't this a simpler and more readable patch?

The idea is okay (we talked about it already), but I don't like doing
it now because it only migrates *one* of the is_owner_or_cap() checks
out of do_utimes().  We could revisit this later in the context of
migrating both checks out of do_utimes(), but I'd prefer to leave that
for now.

> Index: linux/fs/attr.c
> ===================================================================
> --- linux.orig/fs/attr.c        2008-06-03 13:10:11.000000000 +0200
> +++ linux/fs/attr.c     2008-06-04 07:07:23.000000000 +0200
> @@ -51,7 +51,7 @@ int inode_change_ok(struct inode *inode,
>        }
>
>        /* Check for setting the inode time. */
> -       if (ia_valid & (ATTR_MTIME_SET | ATTR_ATIME_SET)) {
> +       if (ia_valid & (ATTR_MTIME_SET | ATTR_ATIME_SET | ATTR_UPDATE_TIMES)) {
>                if (!is_owner_or_cap(inode))
>                        goto error;
>        }
> Index: linux/fs/utimes.c
> ===================================================================
> --- linux.orig/fs/utimes.c      2008-06-03 13:10:11.000000000 +0200
> +++ linux/fs/utimes.c   2008-06-04 07:10:53.000000000 +0200
> @@ -102,9 +102,14 @@ long do_utimes(int dfd, char __user *fil
>        if (error)
>                goto dput_and_out;
>
> -       /* Don't worry, the checks are done in inode_change_ok() */
>        newattrs.ia_valid = ATTR_CTIME | ATTR_MTIME | ATTR_ATIME;
>        if (times) {
> +               /*
> +                * Checking the owner is done in inode_change_ok(),
> +                * even for the special UTIME_OMIT/UTIME_NOW cases.
> +                */
> +               newattrs.ia_valid |= ATTR_UPDATE_TIMES
> +
>                error = -EPERM;
>                 if (IS_APPEND(inode) || IS_IMMUTABLE(inode))
>                        goto mnt_drop_write_and_out;
> Index: linux/include/linux/fs.h
> ===================================================================
> --- linux.orig/include/linux/fs.h       2008-06-03 13:10:25.000000000 +0200
> +++ linux/include/linux/fs.h    2008-06-04 07:07:43.000000000 +0200
> @@ -333,6 +333,7 @@ typedef void (dio_iodone_t)(struct kiocb
>  #define ATTR_FILE      8192
>  #define ATTR_KILL_PRIV 16384
>  #define ATTR_OPEN      32768   /* Truncating from open(O_TRUNC) */
> +#define ATTR_UPDATE_TIMES      (1 << 16)
>
>  /*
>  * This is the Inode Attributes structure, used for notify_change().  It
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/