Re: [hackers] [sbase] [PATCH 2/2] [chmod] Use DIRFIRST

From: David Phillips <david_AT_sighup.nz>
Date: Mon, 2 Oct 2017 11:43:29 +1300

On Sun, Oct 01, 2017 at 12:03:45PM -0700, Michael Forney wrote:
> Here's what POSIX has to say on the matter:
>
> "Some implementations of the chmod utility change the mode of a
> directory before the files in the directory when performing a
> recursive (-R option) change; others change the directory mode after
> the files in the directory. If an application tries to remove read or
> search permission for a file hierarchy, the removal attempt fails if
> the directory is changed first; on the other hand, trying to re-enable
> permissions to a restricted hierarchy fails if directories are changed
> last. Users should not try to make a hierarchy inaccessible to
> themselves."
>
> So it looks like we are conforming whether we use DIRFIRST or not.
> However, based on the last sentence, we probably don't expect users to
> `chmod -R 000` a directory tree and DIRFIRST seems to match a couple
> other implementations I looked at, so I applied this patch.
>
> Thanks!

Yeah, I had identified this tradeoff when making the patch. Unfortunately
it is a mutually exclusive relationship, unless we were to approach it in
a "smarter" manner and examine our gid and uid, the target's gid and uid,
as well as the new mode itself. Then we could try to detect if applying the
fn before calling opendir would result in error. When I first thought of
this method, it sounded a little too sucky for me.

A preliminary version of the patch that I wrote actually "brute forced"
the opendir before calling fn, and if that failed, it also tried calling
it after fn was run, just in case fn made it readable to us. This worked
in that I was able to recursively change trees between extremes such as 000
and 777, but it came with a tradeoff of applying the function twice (on the
way down as well as up), and it just seemed sucky to rely on such a brutish
approach.

If POSIX doesn't specify the behaviour, and our behaviour doesn't suck, I
guess it makes sense for it to match "most" other tools out there. Testing
shows me that both GNU and Solaris versions of chmod seem to act in the same
way as our chmod now does.

Thanks for applying it!
David
Received on Mon Oct 02 2017 - 00:43:29 CEST