On 27.10.2009 14:04, Vincent Zweije wrote:
> On Mon, Oct 26, 2009 at 12:14:36PM -0400, Stephen Harris wrote:
>
> || User1 creates file with permissions 0644
> || User2 opens file for read access on file descriptor 4
> || User1 chmod's directory to 0700
> || User1 chmod's file to 0666
> || User1 verifies no hard links to file
> || User2 can not open the file for read or write access
> || User2 can not write to file descriptor 4
> || User2 _can_ write to /proc/$$/fd/4
> ||
> || Now user2 is expected to be able to have read-access to the file via
> || (he opened it in step 2). If he attempts to write with ">&4" then it
> || silently fails (on Linux, anyway). But access via /proc/$$/fd/4 allows
> || write access.
>
> On Sat, Oct 24, 2009 at 01:46:17AM -0500, Derek Martin wrote:
>
> || That said, the user in the example already has access to the file (in
> || a running process), and would be able to do so again, *if he had
> || access to a directory where the file was hard-linked*. Pavel
> || described that the sysadmin checked for that, but even if this worked
> || as expected, there's a race condition where the user could create the
> || hard link after the sysadmin checked, but before the permissions were
> || corrected. Unlikely, I know... but possible.
>
> That race is easily fixed.
No, you're not right.
> After chmodding the directory to 0700, *first*
> check the link count, *then* chmod the file to 0666:
>
> User1 creates file with permissions 0644
> User2 opens file for read access on file descriptor 4
> User1 chmod's directory to 0700
> User1 verifies no hard links to file
Here's a window, during which User2 is able to create a hardlink and that will
remain unnoticed by User1. There's no way to perform link check and
conditionally do chmod in an atomic manner.
> User1 chmod's file to 0666
> User2 can not open the file for read or write access
> User2 can not write to file descriptor 4
> User2 _can_ write to /proc/$$/fd/4
>
> Excluding the /proc route, at no point during this sequence, User2 could
> have opened the file for writing. Therefore, User1 expects (justified,
> imo) that User2 cannot write to the file. The writability of /proc/$$/fd/4
> violates this expectation.
>
Again, you're not right. See above.
--
> On Mon, Oct 26, 2009 at 12:14:36PM -0400, Stephen Harris wrote:
>
> || User1 creates file with permissions 0644
> || User2 opens file for read access on file descriptor 4
> || User1 chmod's directory to 0700
> || User1 chmod's file to 0666
> || User1 verifies no hard links to file
> || User2 can not open the file for read or write access
> || User2 can not write to file descriptor 4
> || User2 _can_ write to /proc/$$/fd/4
> ||
> || Now user2 is expected to be able to have read-access to the file via
> || (he opened it in step 2). If he attempts to write with ">&4" then it
> || silently fails (on Linux, anyway). But access via /proc/$$/fd/4 allows
> || write access.
>
> On Sat, Oct 24, 2009 at 01:46:17AM -0500, Derek Martin wrote:
>
> || That said, the user in the example already has access to the file (in
> || a running process), and would be able to do so again, *if he had
> || access to a directory where the file was hard-linked*. Pavel
> || described that the sysadmin checked for that, but even if this worked
> || as expected, there's a race condition where the user could create the
> || hard link after the sysadmin checked, but before the permissions were
> || corrected. Unlikely, I know... but possible.
>
> That race is easily fixed.
No, you're not right.
> After chmodding the directory to 0700, *first*
> check the link count, *then* chmod the file to 0666:
>
> User1 creates file with permissions 0644
> User2 opens file for read access on file descriptor 4
> User1 chmod's directory to 0700
> User1 verifies no hard links to file
Here's a window, during which User2 is able to create a hardlink and that will
remain unnoticed by User1. There's no way to perform link check and
conditionally do chmod in an atomic manner.
> User1 chmod's file to 0666
> User2 can not open the file for read or write access
> User2 can not write to file descriptor 4
> User2 _can_ write to /proc/$$/fd/4
>
> Excluding the /proc route, at no point during this sequence, User2 could
> have opened the file for writing. Therefore, User1 expects (justified,
> imo) that User2 cannot write to the file. The writability of /proc/$$/fd/4
> violates this expectation.
>
Again, you're not right. See above.
--
Sincerely Your, Dan.
[ reply ]