[lkml]   [2008]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] utimensat() non-conformances and fixes [v3]
On Tue, Jun 3, 2008 at 1:22 PM, Al Viro <> wrote:
> On Tue, Jun 03, 2008 at 01:13:00PM +0200, Miklos Szeredi wrote:
>> > > I'm not sure of the correct way to get the required nameidata (to do a
>> > > vfs_permission() call) from the file descriptor. Can you give me a
>> > > tip there?
>> >
>> > Could you point me at the right way of doing this?
>> You don't need nameidata for this at all. Just call permission() with
>> a NULL nameidata.
>> Ugly API? Yes, will be cleaned up if we manage to find some common
>> ground with the VFS maintainers.
> As soon as I'm done with sysctls...
> FWIW, I very much doubt that you are right wrt required permissions, though.
> AFAICS, intent here is "if you can write to file, you can touch the timestamps
> anyway" and having descriptor opened for write gives that, current permissions
> be damned.

The standard is pretty clear on this point:

Only a process with the effective user ID equal to the user ID of the
file, or with write access to the file, or with appropriate privileges
may use futimens( ) or utimensat( ) with a null pointer as the times
argument or with both tv_nsec fields set to the special value

The crucial words here are "a process ... with write access to the
file" -- in other words, the permissions are determined by the
process's credentials, not by the access mode of the file descriptor.
I was not 100% sure on that to start with, so I did check it out with
one of the folk at The Open Group, to make sure of my understanding.

Michael Kerrisk
Linux man-pages maintainer;
Found a bug?

 \ /
  Last update: 2008-06-03 13:31    [W:0.053 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site