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

From: Michael Forney <mforney_AT_mforney.org>
Date: Sun, 1 Oct 2017 12:03:45 -0700

On 2017-09-30, David Phillips <david_AT_sighup.nz> wrote:
> Previosuly, running `chmod 777` on a directory that had no read or
> execute access (e.g. 111 or 000) would cause chmod to throw its
> toys since it was trying to opendir before having added read permission
> to the directory.

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!

> ---
> chmod.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/chmod.c b/chmod.c
> index f671f32..c12d2f4 100644
> --- a/chmod.c
> +++ b/chmod.c
> _AT_@ -32,7 +32,7 @@ int
> main(int argc, char *argv[])
> {
> struct recursor r = { .fn = chmodr, .hist = NULL, .depth = 0, .maxdepth =
> 1,
> - .follow = 'P', .flags = 0 };
> + .follow = 'P', .flags = DIRFIRST };
> size_t i;
>
> argv0 = *argv, argv0 ? (argc--, argv++) : (void *)0;
> --
> 2.14.1
Received on Sun Oct 01 2017 - 21:03:45 CEST