On Sat, May 08, 2004, Marc Olzheim wrote: > On Sat, May 08, 2004 at 05:00:40PM +1000, Tim Robbins wrote: > > Both the current implementation and the proposed new implementation > > try to find the pathname use the namecache without authorization > > checks, then if that fails, go on to read the directories, but this > > time with authorization checks. What is the difference? > > standards/44425 mentions why the current implementation is not a bug in > the standards point of view. > > bin/22291, kern/30527, kern/39331 and kern/55993 are about issues we > have because of the current implementation. 30527 seems to be unrelated... > What would be gained from this patch is: > - consistency > - getcwd() having elevated permission to actually be able to find the > real cwd. The fact that the present implementation is inconsistent is a bug. Moreover, it's a small bug, with a patch already provided in standards/44425. Therefore, this is poor justification for completely replacing the current implementation. Recall that in POSIX, it's perectly legal to refuse to reveal the cwd when an the user lacks search permission to some ancestor directory. Moreover, refusing permission may be safer because it respects users' intent to revoke search permission. The present implementation is also less complex because it defers the hard cases to userland. On the other hand, we need to support the full-blown kernel version in the Linuxolator anyway, so we might as well do it once and do it right. But this doesn't necessarily mean it's a good idea to bypass restrictions on read permission. So in summary, I'm in support of the idea of unifying our getcwd implementations, modulo some of the details...Received on Sat May 08 2004 - 06:03:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:53 UTC