Fixes #35402 - allow apache to read /var/lib/foreman#146
Conversation
…t_t" This reverts commit 7078059.
This is needed to allow it to serve static assets which are deployed to /var/lib/foreman/public
ekohl
left a comment
ekohl
left a comment
There was a problem hiding this comment.
I do wonder why Dynflow wants to read these. I'll try a reproducer first.
| stream_connect_pattern(httpd_t, foreman_var_run_t, foreman_var_run_t, foreman_rails_t) | ||
|
|
||
| # Allow Apache access to static assets | ||
| allow httpd_t foreman_lib_t:file { getattr map open read }; |
There was a problem hiding this comment.
It also allows reading everything in /var/lib/foreman. Now that we no longer store the (potential) sqlite DB there, I guess it's fairly safe, though I can imagine we'd store more secrets there in the future.
I've been thinking about introducing its own type that both Foreman and Apache are able to read. It may also be that you must set config.public_file_server.enabled = false in the settings and then it no longer tries to read them.
ekohl
left a comment
ekohl
left a comment
There was a problem hiding this comment.
I did a bit of digging and this is where it shows up:
https://github.com/rails/sprockets/blob/3deb9f4b0f3f7adb2e7dd8adce362de36935982b/lib/sprockets/manifest_utils.rb#L27-L47
So it's trying to list the assets directory to find `.sprockets-manifest*.json. We also do a similar thing here:
https://github.com/theforeman/foreman/blob/08b9713e84aa8be7bc2f12d654bf1102bac20e32/config/initializers/assets.rb#L27
I'm getting the impression we basically do both: first load the regular sprockets-rails integration (which lists the directory if no filename was specified) and then we override the whole manifest setting with something else.
It looks like a better integration would set config.assets.manifest somewhere during very early init. We can move this file out of public/assets since AFAIK it's not meant to be read by clients (which is why it has a hash and is a hidden file). With this we do need to take care that we have all known plugins, and that may be too late in the process.
Another option is to create a new directory, something like config/assets/manifests and we dump all JSON files there and blindly merge.
This would be opening a whole new can of worms and I wonder if we want to do that. Rails 7 has made sprockets optional and defaults to importmaps. https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851 has more, but right now I'm leaning to merging this and revisiting our assets when we migrate to Rails 7.
3 participants
No description provided.