lkml.org 
[lkml]   [2004]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.6.5-mm4] sys_access race fix
* Fabian Frederick (Fabian.Frederick@skynet.be) wrote:
> Well, the only major function behind user_walk is path_lookup.
> This one has some calls with the nameidata.Other process seems
> current->fs->xxx relevant read-only.Maybe you mean the
> read_lock(&current->fs->lock) which could bring a deadlock as we
> task->lock before ?

No, point is simply that there's implicit permission check in
__user_walk().

> If user_walk had to run in ruid, why would we have permission() then ?

It's how the standards require the call to be implemented. The
access(2) check verifies access to the pathname using the ruid not euid.
Part of valid access includes search access on the directory elements of
the full pathname. Those tests are done during __user_walk.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.037 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site