lkml.org 
[lkml]   [2006]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: FMODE_EXEC or alike?
    On 2/21/06, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
    > On Mon, 2006-02-20 at 21:51 -0800, Andrew Morton wrote:
    > > Oleg Drokin <green@linuxhacker.ru> wrote:
    > > >
    > > > Hello!
    > > >
    > > > We are working on a lustre client that would not require any patches
    > > > to linux kernel. And there are few things that would be nice to have
    > > > that I'd like your input on.
    > > >
    > > > One of those is FMODE_EXEC - to correctly detect cross-node situations with
    > > > executing a file that is opened for write or the other way around, we need
    > > > something like this extra file mode to be present (and used as a file open
    > > > mode when opening files for exection, e.g. in fs/exec.c)
    > > > Do you think there is a chance this can be included into vanilla kernel,
    > > > or is there a better solution I oversee?
    > > > I am just thinking about something as simple as this
    > > > (with some suitable FMODE_EXEC define, of course):
    > > >
    > > > --- linux/fs/exec.c.orig 2006-02-21 00:11:47.000000000 +0200
    > > > +++ linux/fs/exec.c 2006-02-21 00:12:24.000000000 +0200
    > > > @@ -127,7 +127,7 @@ asmlinkage long sys_uselib(const char __
    > > > struct nameidata nd;
    > > > int error;
    > > >
    > > > - error = __user_path_lookup_open(library, LOOKUP_FOLLOW, &nd, FMODE_READ);
    > > > + error = __user_path_lookup_open(library, LOOKUP_FOLLOW, &nd, FMODE_READ|FMODE_EXEC);
    > > > if (error)
    > > > goto out;
    > > >
    > > > @@ -477,7 +477,7 @@ struct file *open_exec(const char *name)
    > > > int err;
    > > > struct file *file;
    > > >
    > > > - err = path_lookup_open(name, LOOKUP_FOLLOW, &nd, FMODE_READ);
    > > > + err = path_lookup_open(name, LOOKUP_FOLLOW, &nd, FMODE_READ|FMODE_EXEC);
    > > > file = ERR_PTR(err);
    > > >
    > > > if (!err) {
    > > >
    > >
    > > Such a patch would have zero runtime cost. I'd have no problem carrying
    > > that if it makes things easier for lustre, personally.
    > >
    > > We would need to understand whether this is needed by other distributed
    > > filesystems and if so, whether the proposed implementation is suitable and
    > > sufficient.
    >
    > Hmm.... We might possibly want to use that for NFSv4 at some point in
    > order to deny write access to the file to other clients while it is in
    > use.

    When done with regards to failing a write if anyone has mapped the
    file for executing it, or failing the execute if it's open/mmaped for
    write, I can't really see the difference between local, remote and
    clustered filesystems...

    --
    Greetz, Antonio Vargas aka winden of network

    http://wind.codepixel.com/
    windNOenSPAMntw@gmail.com
    thesameasabove@amigascne.org

    Every day, every year
    you have to work
    you have to study
    you have to scene.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-02-21 15:19    [W:0.025 / U:179.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site