-
-
Notifications
You must be signed in to change notification settings - Fork 825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standalone install - check upload directory is writable #29354
Standalone install - check upload directory is writable #29354
Conversation
🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷 Introduction for new contributors...
Quick links for reviewers...
|
The issue associated with the Pull Request can be viewed at https://lab.civicrm.org/dev/core/-/issues/4988 |
35937c0
to
8909112
Compare
8909112
to
bcab1ef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @ufundo I've made some comments here based on a read-through of the code; I've not tried running it yet.
Thanks for the work! It's interesting to learn about setup plugins - new to me!
setup/plugins/installFiles/StandaloneCivicrmFilesPath.civi-setup.php
Outdated
Show resolved
Hide resolved
else { | ||
$e->addInfo('system', 'civicrmFilesPathWritable', sprintf('The civicrm files dir "%s" can be created.', $civicrmFilesDirectory)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This else hits cases where the sentence is not true, e.g.
- There is no dir defined in config.
- The dir already exists
Suggest just removing it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point! have added the conditions (I feel like it could be a useful notice for user to see that it's creating the directory where they want it/somewhere sensible)
setup/plugins/installFiles/StandaloneCivicrmFilesPath.civi-setup.php
Outdated
Show resolved
Hide resolved
Civi\Setup::log()->info('[StandaloneCivicrmFilesPath.civi-setup.php] mkdir "{path}"', [ | ||
'path' => $civicrmFilesDirectory, | ||
]); | ||
mkdir($civicrmFilesDirectory, 0777, TRUE); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0777 is very open; it makes the uploaded data world-read-writable. If the ancestor dirs do not provide protection against access this could mean some other process (e.g. another website on same server) could write files in the civi upload dir.
Also, I note that the following line calls FileUtil which does the same thing- we don't need that call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To my eye, the parameter here looks like a formality necessitated by setting $recursive=TRUE
. 0777
is the PHP default, and it's still subject to umask
. It's consistent with how CreateTemplateCompilePath
does it.
Due to umask handling, mkdir(...0777...)
doesn't have the same meaning as chmod(...0777...)
(in FileUtil::makeWebWritable()
):
mkdir()
speaks softly: "I'm fine with anything up to 0777, but the local system might prefer to change it viaumask
."chmod()
speaks loudly: "Set this thing to 0777. It will be public!"
The part that's being overly prescriptive is makeWebWritable()
. Fixing that would kinda be a different feature, tho, wouldn't it? (e.g. "configurable permissioning"?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Full disclosure: I just blindly copied from CreateTemplateCompilePath
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the webserver is able to create the file, can we assume it's the file owner, and so 700 or 770 be ok?
Or is this also called by CLI install, in which case you might be running as a different user. Still in this case 770 and make sure you have a shared group seems better place to get to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point @totten re mkdir respecting umask.
I think we just ditch the 2nd call that applies 0777 and we're done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(@ufundo) Or is this also called by CLI install, in which case you might be running as a different user.
Quite right.
(@totten) The part that's being overly prescriptive is
makeWebWritable()
. Fixing that would kinda be a different feature, tho, wouldn't it? (e.g. "configurable permissioning"?)(@ufundo) Still in this case 770 and make sure you have a shared group seems better place to get to?
(@artfulrobot) I think we just ditch the 2nd call that applies 0777 and we're done.
Ugh, messy area.
Unfortunately, in the wild, 0770
, 0700
, and inherited-umask are just as likely to leave a broken environment. Even if the person knows about the console-user/web-user split, their primary-group is usually mismatched (myuser:staff
or myuser:myuser
not myuser:www-data
not myuser:apache
), and they usually don't have any suitable policy/inheritance mechanism (like sticky bits or umasks or setfacl). And even if they did, it's hard to -preconfigure enough nuance to distinguish "gid/perms for new code files" (re:unzip
) and "gid/perms for new data files" (re:cv core:install
).
The thing about 0777
for initializing data-folders is.... it just works. It's not awful (in the common contexts of a dedicated web-server or personal workstation or container), but it's not good either (wrt defense-in-depth or consistently-mutually access). For a professional admin, it's usually not what you want. But it's simple; it's a universally recognized quantity; and you can tune post-install.
IMHO:
- The KISS thing is basically what you have already (call
makeWebWritable()
). - A bonus thing would be an option in the install-model (
$model->dataDirMode
). TeachmakeWebWritable()
to abide. The web-based installer and CLI-installer can set this differently. Folks doing system-automation can tune it. - Another bonus thing would be to write more detailed detection/training/advice. ("Your source-code is owned by a different user? Do X..." or "Your server has a user named
www-data
? Do Y...") You would probably target this first as a status-check (which applies to post-install as well as system-restores, migrations, etc).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kiss
Makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks both.
On that basis I'd be quite keen to leave the makeWebWritable
for now.. its consistent with the templates_c
behaviour and if anyone comes along to improve that they'll pick up this occurence?
e23e886
to
340d5e6
Compare
I think the fails are spurious... retest this please? 🙂 |
@ufundo If you look at the latest test results, the "Console" shows this:
|
340d5e6
to
82418bf
Compare
Oops sorry 🤦 should be fixed now |
@totten or @artfulrobot - I think this could be mergeable now? |
I did this to test:
Edited the composer file:
Then
Then navigate to the web installer, enter database details (create database first). I then saw this: I needed to:
Then the installer continued. |
Merging based on tests - I think the behaviour I documented is what's supposed to happen. Thanks @ufundo |
Before
Installing Standalone using the composer starter template method fails unexpectedly if the
civicrm.files
directory doesn't exist or isn't writeable.After
We check the directory is writeable before starting the installer (in the same way as we do already for
templates_c
).Technical Details
I've added this as Standalone specific, but is there any reason we don't do this for other CMSes?
It's particularly relevant for Standalone because the warning that the directory isn't writeable causes a crash before we have installed the SessionHandler. See https://lab.civicrm.org/dev/core/-/issues/4988