Re: A problem with noacl+umask+chmod result

[Orgad Shaneh <orgads@gmail.com>]

On Fri, Apr 9, 2021 at 4:50 AM Andrey Repin <anrdaemon@yandex.ru> wrote:
>
> Greetings, Orgad Shaneh!
>
> > On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh <orgads@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> If a filesystem is mounted with noacl, calling chmod to add write
> >> permissions after umasking this permission doesn't work. Demonstrated
> >> with command-line and C++.
> >>
> >> Did I miss something or is this a real bug? According to umask man, it
> >> should only affect newly created files and directories, but I didn't
> >> find anything that relates to chmod.
> >>
> >> Command-line:
> >> touch foo
> >> ls -l foo
> >> # -rw-r--r-- ... foo
> >> umask 200
> >> chmod 0 foo
> >> ls -l foo
> >> # -r--r--r-- ... foo
> >> chmod 200 foo
> >> ls -l foo
> >> # -r--r--r-- ... foo
> >> # Expected to have rw
>
> > Marco Atzeri replied to the mailing list but did not CC me, so I
> > didn't receive it:
>
> The expectation is that you subscribe to the list of interest.

Why? If I report a bug, I'm interested in this bug, and I don't want
to receive dozens of emails every day about other issues.

Every time you report a bug to a project on github/jira/whatever, you
subscribe to everything in this project?

> >> without ACL you can not expect the POSIX scheme to properly work.
> >> see
> >> https://cygwin.com/cygwin-ug-net/ntsec.html
> >> to understand how Cygwin uses ACL to mimic POSIX permissions
>
> > Thanks Marco!
>
> > I'm well aware of that. I don't expect it to work properly. From what
> > I know, it can only set/unset user write bit. Read bits are always
> > enabled, even on chmod 0.
>
> > What I do expect is that the write bit will not be affected by umask.
> > umask should only affect newly created files, not direct chmod
> > commands.
>
> Yet again: using chmod on noacl filesystem is likely to cause more harm than
> good. You may very well end up with an unusable filesystem until you fix
> permissions by hands.

With noacl, chmod is capable of setting and unsetting the user write
bit, and I expect it to do that.

I actually found this issue because CMake unit tests failed for me on
MSYS which sets noacl.

Anyway, I found the curprit. The problem is not with chmod, but with stat.

fhandler_base::fstat_helper has this line:
      /* This fakes the permissions of all files to match the current umask. */
      buf->st_mode &= ~(cygheap->umask);

So chmod does set the write bit correctly, but stat doesn't report it.

I can see why this is needed, so I'll adapt the CMake tests to workaround this.

Thank you!

- Orgad