lkml.org 
[lkml]   [2000]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] devfs and symlinks--2.3.48
    Richard Gooch wrote:
    >
    > Jamie Lokier writes:
    > > Richard Gooch wrote:
    > > > Symlink permissions should not matter. The kernel doesn't care, and
    > > > neither should applications. If some application out there is doing
    > > > lstat(2), I'd rather break it and see it fixed, since it's probably
    > > > broken in other ways too.
    > >
    > > For procfs, symlink permissions do matter.
    >
    > Procfs is special in that way. For devfs, it doesn't matter.
    >

    If it doesn't matter so much, why not make them like every other symlink
    on the system (with the exception of that one in procfs, of course). My
    reasoning is, if it really does not matter, why take a chance on
    breaking someone else's program, simply out of stubbornness? That's
    just wrong. I mean, I'm sure it's extremely rare that someone would use
    lstat to access a device, but it could happen, I reckon. And that does
    not necessarily mean that that program is broken. I'm sure there are
    situations in which it would be preferable to use lstat over stat. Just
    because I don't know enough to actually *think* of such a situation, at
    this time, does not mean there isn't one.

    So far, I haven't seen any explanation of why /dev symlinks are created
    the way they are. The only thing I can figure is that it's sheer
    orneriness, with no programatical foundation.

    The little change I made to base.c only affects symlinks in the root of
    /dev--it doesn't descend into directories. Kinda weird--I thought
    devfs_mk_symlink was used for all symlinks in devfs. If you would tell
    me where I should add another mode bit, I'd be happy to make the changes
    to suit my personal preferences, and not tell anyone else about them...

    Richard: BTW, you were mistaken about X--I couldn't find hide nor hair
    of a true lstat (there was one #define lstat(a,b) stat(a,b)--but I don't
    think that counts). No, the problem was the console.perms, used by
    pam. Oh, and /dev/tty is hardcoded. Just an FYI...that was on 3.3.6.
    Dammit, just so many things that can go wrong!! The challenge truly
    makes it interesting... :)

    ciao,
    --
    Matthew Vanecek
    Visit my Website at http://mysite.directlink.net/linuxguy
    For answers type: perl -e 'print
    $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
    *****************************************************************
    For 93 million miles, there is nothing between the sun and my shadow
    except me. I'm always getting in the way of something...

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:0.022 / U:0.336 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site