[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.022 / U:19.064 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site