lkml.org 
[lkml]   [2000]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] devfs and symlinks--2.3.48
    Matthew Vanecek writes:
    > 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.

    If a programme depends on the write bit of a symlink, it's broken. In
    this case, you may say it doesn't matter, but it makes me think that
    the programme is probably broken in other ways. If I leave devfs as it
    is, it forces someone to look at the buggy programme, which increases
    the chance that it will receive a mini-audit, something it is clearly
    in need of.

    > 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.

    Why would the permissions on the symlink matter, then? The only way I
    can see how symlink permissions matter is if a call is made to
    lstat(2). Both stat(2) and access(2) traverse the link.

    > Oh, and /dev/tty is hardcoded. Just an FYI...that was on 3.3.6.

    /dev/tty shouldn't matter, as that is a standard name that devfs (not
    devfsd) creates. The problems lie with /dev/ttyN (moved to /dev/vc).

    > Dammit, just so many things that can go wrong!! The challenge truly
    > makes it interesting... :)

    Yep, so many assumptions :-)

    Regards,

    Richard....
    Permanent: rgooch@atnf.csiro.au
    Current: rgooch@ras.ucalgary.ca
    -
    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    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean