GNU bug report logs - #22185
Operation not permitted for `touch -d` on 777 file

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22185 in the body.
You can then email your comments to 22185 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Silvio Ricardo Cordeiro <silvioricardoc <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Operation not permitted for `touch -d` on 777 file
Date: Wed, 16 Dec 2015 12:39:41 -0200

[Message part 1 (text/plain, inline)]

The following code fails whenever the specified date is different from
`now`:

$ mkdir testdir; chmod 777 testdir; cd testdir
$ touch file; chmod 777 file
$ su another_user
$ touch -d 'now' file  # works
$ touch -d 'yesterday' file  # fails
touch: setting times of ‘file’: Operation not permitted

I see no description of that in the documentation, and it just seems wrong.
If other users have full control over the file (and surrounding directory),
shouldn't they be able to change its date?

The same behavior is seen with `touch -t`.

Best,
-- 
Silvio Ricardo Cordeiro

[Message part 2 (text/html, inline)]

Message #8 received at 22185 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Silvio Ricardo Cordeiro <silvioricardoc <at> gmail.com>, 22185 <at> debbugs.gnu.org
Subject: Re: bug#22185: Operation not permitted for `touch -d` on 777 file
Date: Wed, 16 Dec 2015 13:19:59 -0500

Hello,

On 12/16/2015 09:39 AM, Silvio Ricardo Cordeiro wrote:
> The following code fails whenever the specified date is different from `now`:
>
> $ mkdir testdir; chmod 777 testdir; cd testdir
> $ touch file; chmod 777 file
> $ su another_user
> $ touch -d 'now' file  # works
> $ touch -d 'yesterday' file  # fails
> touch: setting times of ‘file’: Operation not permitted
>
> I see no description of that in the documentation, and it just seems wrong. If other users have full control over the file (and surrounding directory), shouldn't they be able to change its date?
>

Trying first to reproduce and understand the issue, I'm seeing this:

1.
When running with 'now', the utimensat(2) syscall is passed NULL as the timespec parameter:

    $ strace -e utimensat touch -d 'now' file
    utimensat(0, NULL, NULL, 0)             = 0
    +++ exited with 0 +++

2.
When running with 'yesterday', the syscall is passed a timespec containing a specific time:

    $ strace -e utimensat touch -d 'yesterday' file
    utimensat(0, NULL, {{1450202605, 538896888}, {1450202605, 538896888}}, 0) = -1 EPERM (Operation not permitted)
    touch: setting times of ‘file’: Operation not permitted
    +++ exited with 1 +++

3.
This coincides with the touch.c code ( http://lingrok.org/xref/coreutils/src/touch.c#157 ),
with the following comment:

    157  if (amtime_now)
    158    {
    159      /* Pass NULL to futimens so it will not fail if we have
    160         write access to the file, but don't own it.  */
    161      t = NULL;
    162    }

4.
The linux kernel syscall (if I traced the flow correctly) ends up in 'utimes_common' ( http://lingrok.org/xref/linux-linus/fs/utimes.c#51 ).
The code block that is executed with timespec=NULL is this ( http://lingrok.org/xref/linux-linus/fs/utimes.c#89 ):

    90		/*
    91		 * If times is NULL (or both times are UTIME_NOW),
    92		 * then we need to check permissions, because
    93		 * inode_change_ok() won't do it.
    94		 */
    95		error = -EACCES;
    96                if (IS_IMMUTABLE(inode))
    97			goto mnt_drop_write_and_out;
    98
    99		if (!inode_owner_or_capable(inode)) {
    100			error = inode_permission(inode, MAY_WRITE);
    101			if (error)
    102				goto mnt_drop_write_and_out;
    103		}

Which seems to indicate that if the request is to change the time to 'now' using NULL (as opposed to the spelled-out timespec value that is equivalent to the current time), then the permission check go through a slightly different code path (using 'inode_permissions(..., MAY_WRITE)'),
and perhaps checking for write-permissions (which you have) as opposed to ownership (which you don't).

If the above is correct, then this is not a bug in coreutils' touch per-se, but a linux kernel behavior.

Comments very welcomed,
regards,
 - assaf

Message #11 received at 22185 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Silvio Ricardo Cordeiro <silvioricardoc <at> gmail.com>, 22185 <at> debbugs.gnu.org
Subject: Re: bug#22185: Operation not permitted for `touch -d` on 777 file
Date: Wed, 16 Dec 2015 13:27:50 -0500

tag 22185 notabug
close 22185
stop

Additional information:

On 12/16/2015 01:19 PM, Assaf Gordon wrote:
> Hello,
>
> On 12/16/2015 09:39 AM, Silvio Ricardo Cordeiro wrote:
>> The following code fails whenever the specified date is different from `now`:

<...>
>>
>> I see no description of that in the documentation, and it just seems wrong. If other users have full control over the file (and surrounding directory), shouldn't they be able to change its date?

<...>

> If the above is correct, then this is not a bug in coreutils' touch per-se, but a linux kernel behavior.

I should've looked first at the man page... which states it clearly:

from 'man 2 utimesnsat' :
====
  Permissions requirements
       To  set  both  file timestamps to the current time (i.e., times is NULL, or both tv_nsec fields
       specify UTIME_NOW), either:

       1. the caller must have write access to the file;

       2. the caller's effective user ID must match the owner of the file; or

       3. the caller must have appropriate privileges.

       To make any change other than setting both timestamps to the current time (i.e., times  is  not
       NULL,  and  both  tv_nsec fields are not UTIME_NOW and both tv_nsec fields are not UTIME_OMIT),
       either condition 2 or 3 above must apply.
====

Which means write access (condition 1) is not sufficient to set the time to anything except 'now'.
Therefor it is not a coreutils bug - but a linux kernel requirement.

As such, I'm making this as 'closed' - but discussion is welcomed to continue.

regards,
 - assaf

Message #14 received at 22185 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Silvio Ricardo Cordeiro <silvioricardoc <at> gmail.com>, 22185 <at> debbugs.gnu.org
Subject: Re: bug#22185: Operation not permitted for `touch -d` on 777 file
Date: Wed, 16 Dec 2015 12:59:52 -0800

Silvio Ricardo Cordeiro wrote:
> If other users have full control over the file (and surrounding directory),
> shouldn't they be able to change its date?

Mode 777 does not mean full control; it merely means read, write, and execute 
access is granted to everybody. Other users still cannot chmod the file, for 
example; nor can they set the file's time stamps in arbitrary ways.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.