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    [W:0.083 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site