| commit | bd5391243cdd92d9e0abee5ba1a506170b18d072 | |
| author | Andreas Gohr <andi@splitbrain.org> | |
| Sat, 14 Aug 2021 09:06:31 +0000 (14 11:06 +0200) | ||
| committer | Andreas Gohr <andi@splitbrain.org> | |
| Sat, 14 Aug 2021 09:43:40 +0000 (14 11:43 +0200) | ||
| tree | 8cbe9f3e5722a3da7294a081d755f3e711f4c527 | treesnapshot (tar.gz zip) |
| parent | 1e519eb5339e02a75ee7aba2a1a5555f09ff8818 | commitdiff |
:fire: fix the calculation of file permissons
Our config allows to set the values for `dmode` and `fmode` to allow
users to explicitly define which permissions directories and files
should have.
To avoid unnessary chmod operations, we check the current umask to
compare what permissions files and directories would get witout our
intervention. If the result is already what the user wants, no chmods
will happen later on. Otherwise we set new configs called `dperm` and
`fperm` which will be used in chmod ops. This is done in
`init_creationmodes()`
When we created new directories, we used to pass the original `dmode`
config to `mkdir()`. The system will then apply the umask to that
`dmode`.
This means the resulting directory will *always* have different
permissions than `dmode`, *always* requiring a chmod operation.
That's silly.
**Breaking Change:** This patch removes the passing of `dmode` as
second parameter to all `mkdir` calls, making it default to `0700`
which is also what we test against in `init_creationmodes()`.
Plugins not relying on our `io_*` functions and do create their own
directories and which currenlty pass `dmode` to it need to be
adjusted to remove that second parameter.
Users may want to reapply the proper file permissions to their data
folder.
**Revert:** In 9fdcc8fcd87114ca59a1764a84d213a53c655c8c @movatica
introduced a change to `init_creationmodes()` that compared the umask
against `fmode` instead of `0666`. I merged it because it looked logical
when compared to the code for directories which compared against `dmode`
as described above. However we do not pass `fmode` to any file creation
methods (that's not possible).
The result is that all changes made in the `fmode` setting resulted
in the wrong permissions for newly created files as first reported in
https://forum.dokuwiki.org/d/19463-setting-fmode-not-working-as-intended
I'm unsure about the orginal motivation behind @movatica's change. The
"fix" however, is wrong.
**Tests:** This patch introduces an integration test that will check the
actual results of directory and file creations under various umask,
`dmode` and `fmode` settings.
Our config allows to set the values for `dmode` and `fmode` to allow
users to explicitly define which permissions directories and files
should have.
To avoid unnessary chmod operations, we check the current umask to
compare what permissions files and directories would get witout our
intervention. If the result is already what the user wants, no chmods
will happen later on. Otherwise we set new configs called `dperm` and
`fperm` which will be used in chmod ops. This is done in
`init_creationmodes()`
When we created new directories, we used to pass the original `dmode`
config to `mkdir()`. The system will then apply the umask to that
`dmode`.
This means the resulting directory will *always* have different
permissions than `dmode`, *always* requiring a chmod operation.
That's silly.
**Breaking Change:** This patch removes the passing of `dmode` as
second parameter to all `mkdir` calls, making it default to `0700`
which is also what we test against in `init_creationmodes()`.
Plugins not relying on our `io_*` functions and do create their own
directories and which currenlty pass `dmode` to it need to be
adjusted to remove that second parameter.
Users may want to reapply the proper file permissions to their data
folder.
**Revert:** In 9fdcc8fcd87114ca59a1764a84d213a53c655c8c @movatica
introduced a change to `init_creationmodes()` that compared the umask
against `fmode` instead of `0666`. I merged it because it looked logical
when compared to the code for directories which compared against `dmode`
as described above. However we do not pass `fmode` to any file creation
methods (that's not possible).
The result is that all changes made in the `fmode` setting resulted
in the wrong permissions for newly created files as first reported in
https://forum.dokuwiki.org/d/19463-setting-fmode-not-working-as-intended
I'm unsure about the orginal motivation behind @movatica's change. The
"fix" however, is wrong.
**Tests:** This patch introduces an integration test that will check the
actual results of directory and file creations under various umask,
`dmode` and `fmode` settings.