Messages in this thread | | | Date | Mon, 6 Mar 2000 14:12:07 +1100 | From | Richard Gooch <> | Subject | Re: [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/
| |