From 2910b7c5b1d55bc304344b584a25ea571a9075fb Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 24 May 2012 23:08:09 +0200 Subject: Prepare toolchain/logs/master branch. --- open_issues/dir-lookup_authority.mdwn | 68 ----------------------------------- 1 file changed, 68 deletions(-) delete mode 100644 open_issues/dir-lookup_authority.mdwn (limited to 'open_issues/dir-lookup_authority.mdwn') diff --git a/open_issues/dir-lookup_authority.mdwn b/open_issues/dir-lookup_authority.mdwn deleted file mode 100644 index 64866eb5..00000000 --- a/open_issues/dir-lookup_authority.mdwn +++ /dev/null @@ -1,68 +0,0 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_hurd]] - -IRC, unknown channel, unknown date. - - I have discovered a bug in the dir-lookup protocol though - Currently, I'm investigating the bug a bit further - when doing dir-lookups with several path components, the look-up is done with the authority of the user who opened the directory, as opposed to the user doing the lookup - e.g, consider foo/bar/baz, where bar can only be used by its owner and foo and baz are world readable - if foo is opened, then transferred to another user, he can open baz, which he shouldn't be able to - this is possible where foo/bar/baz is within a single translator, and the lookup is done in a single dir-lookup - cfhammar: I'm not sure this is a bug - I have a test case that triggers the bug, and another that doesn't which currently confuses me - cfhammar: it's probably not very usual to pass around open directory ports; but if somebody does it, it's probably actually desired that it keeps the authority - it's kinda consistent with passing normal FDs - antrik: it should only allow accesses to entries not sub-entries - antrik: it isn't allowed in Linux atleast, and I'm guessing it's mandated by posix - also note that a more common scenario is a process that opens a directory and then drops authority - probably more common, that is - cfhammar: I'm not really familiar with directory access functions... I wasn't even aware that it's possible to pass around directory FDs - but if it is, it would indeed be good to know what POSIX says about this - cfhammar: I don't see how this is related?... - antrik: after the process has dropped authority it can still make lookups in directories that it should no longer be able to - cfhammar: interesting point... - cfhammar: do you think this is fixable? - antrik: Not without (defacto) changing the interface - e.g only looking up a singe path component at a time - or doing the auth check lazily on io_reauthenticate - cfhammar: yeah, obviously it's not possible without an API change. I just wonder whether it's possible without throwing the current auth/lookup mechanism overboard alltogether... - antrik: both my solutions are only minor changes to the API, but fairly major in the sense that we need to change all callers :-( - diskfs_S_dir_lookup is a very large function, for example - cfhammar: OK - cfhammar: I wonder whether there is a possible transition path without breaking all existing installations... - we could provide a new RPC while supporting the old one - note that changing fs.defs only affects glibc and the Hurd, normal apps should be fine - cfhammar: have you posted your findings to the ML yet? - No, I'm still investigating why my second test-case doesn't trigger the bug - Intrestingly it's the one using all POSIX functions... - Perhaps its a bug that maskes the lookup bug ;-) - I guess there is some quirk which you do not fully understand yet :-) - Oh, there's always a new quirk to find in the Hurd :-) - antrik: seems that dir_lookup isn't buggy after all - antrik: as all FDs are reauthenticated on setauth - ah - antrik: and (presumably) ports are unauthenticated and reauthenticated when transfered - yeah, that's the idea behind the auth protocol... - users obtain specific capabilities by authenticating generic ports against their own ID - I didn't really have a coherent view on how open flags are handled on reauth - it seems open flags always win, so that a O_READ port that is unauthed is still readable - not sure what you mean - if I open a file to read it, then reauth it with a user that isn't permitted to read it, I can still read from it - (as it should be) - by contrast permission to do lookups in a directory is determined by who authed it - so I won't be able to do lookups after a reauth, if it's not permitted by the file bits - Mmm, openat should however be able to - since you've first opened the directory with the auth - it isn't since open FDs are reauthed on setauth - not sure whether it should though, Linux behaves the same way atleast - though it could be done with POSIX.2008's O_SEARCH open flag -- cgit v1.2.3