WEBMKS Failed in Najdorf Version

[ccesario]

Hi folks, currently Im running ManageIQ Lasker version, and VMware WebMKS Console it working as expected.
Today I tried upgrade this appliance to Najdorf version and I got error with WebMKS, so I download the Najdorf VMware appliance stable version and deploy it, but the same problem happen.

When I try access VMware WebMKS console I got the following screen

Does someone has any tip abou fix it ?

Regards
Carlos

[Fryguy]

@agrare ^?

[agrare]

@ccesario do you see any errors in your /var/www/miq/vmdb/log/remote_console.log?

I just tried this on the latest version and see this:

[----] E, [2022-08-18T13:28:22.256379 #8255:d37c] ERROR -- remote_console: RemoteConsole proxy for VM 20 errored with Permission denied @ rb_sysopen - certs/server.cer /var/www/miq/vmdb/lib/remote_console/client_adapter/ssl_socket.rb:23:in `initialize'
/var/www/miq/vmdb/lib/remote_console/client_adapter/ssl_socket.rb:23:in `open'
/var/www/miq/vmdb/lib/remote_console/client_adapter/ssl_socket.rb:23:in `setup_ssl'
/var/www/miq/vmdb/lib/remote_console/client_adapter/ssl_socket.rb:7:in `initialize'
/var/www/miq/vmdb/lib/remote_console/client_adapter/web_mks.rb:9:in `initialize'
/var/www/miq/vmdb/lib/remote_console/client_adapter.rb:11:in `new'
/var/www/miq/vmdb/lib/remote_console/client_adapter.rb:11:in `new'
/var/www/miq/vmdb/lib/remote_console/rack_server.rb:89:in `init_proxy'
/var/www/miq/vmdb/lib/remote_console/rack_server.rb:63:in `call'
/opt/IBM/infrastructure-management-gemset/gems/puma-4.3.12/lib/puma/configuration.rb:228:in `call'
/opt/IBM/infrastructure-management-gemset/gems/puma-4.3.12/lib/puma/server.rb:727:in `handle_request'
/opt/IBM/infrastructure-management-gemset/gems/puma-4.3.12/lib/puma/server.rb:476:in `process_client'
/opt/IBM/infrastructure-management-gemset/gems/puma-4.3.12/lib/puma/server.rb:332:in `block in run'
/opt/IBM/infrastructure-management-gemset/gems/puma-4.3.12/lib/puma/thread_pool.rb:134:in `block in spawn_thread'

If I chmod 0660 certs/* then the console opens up. The issue appears to be the certs are owned by root:manageiq with access perms of 0600 but the remote console worker runs as manageiq:manageiq cc @kbrock

[ccesario]

Hello @agrare,
Thank you by your feedback.

And your tip fix the console access, after chmod 0660 certs/* the console works, but as you mentioned in next post :-(

[agrare]

Separate issue, the console is comically small

(what is this a console for ants?)

cc @jeffibm @GilbertCherrie @DavidResende0

[ccesario]

Hello, about this issue, can you suggest any tip for fix it ?

Regards
Carlos

[agrare]

I'm going to create a separate bug for this

[agrare]

ManageIQ/manageiq-ui-classic#8419

[ccesario]

@agrare Thank you!

[kbrock]

To be honest, not super excited to have our web process (as manageiq user) able to read (and possibly write) the http ssl private key.

We made proper provisions for v2_key and looks like we have not properly made provision for other certs. ref - since it is more common, that makes sense.

My current suggested solution is to have the certs owned by manageiq.manageiq, thought as the first sentence suggests, I'm on the fence here.

@ccesario Ccan you verify that you created the ssl keys in a previous version of MIQ and updated the rpms? Or did you create ssl keys in this version of the appliance?

[ccesario]

@kbrock Hi, I tried the both, Update my previous Lasker version (by rpms) and install new version from Najdorf appliance.
Currently in Lasker version my certs are owned by root, like sshot below

And in Najdorf currently is

Regards,

[agrare]

To be honest, not super excited to have our web process (as manageiq user) able to read (and possibly write) the http ssl private key.

...

My current suggested solution is to have the certs owned by manageiq.manageiq

These would seem to be conflicting, I agree I don't like a non-privileged able to write the key (though the same argument could be made for v2_key) which would argue for -rw-r----- root manageiq (aka read/write by root, read by manageiq so remote console can work).

If Apache were to handle all ssl//cert rather than MiqRemoteConsoleWorker then -rw------- root root like it is now but this would probably require a decent amount of rework of the remote console code

[kbrock]

a) yes, this is a contradiction/cession. We have had too many issues trying to implement 640 root.manageiq. Much more success with 660 manageiq.manageiq. chown worked better than chmod with fewer issues. Being owned by root.manageiq is correct, but it had been constant headache.

I did setup umask in the systemd processes but it didn't seem to do what it was told.

[agrare]

I think the issues we had with root.manageiq was when workers running as manageiq user tried to write to it (e.g. log files).
Curious what you were trying to do with umask that didn't work

[kbrock]

If we do a user chown (directory chmod 4775), when a root process writes the file, even with the default umask 0755, then the file will be changed over to user manageiq.manageiq 640 and it will be writeable by manageiq, and things will work well.

If we just want group chown (directory chmod 2775), when a root process writes the file, it will be owned by root.manageiq 640 and we blow up writing logs as the group (not the owner).

So we just seemed to have files owned by manageiq.manageiq to simplify the answer of which files are owned by whom.

[kbrock]

• code that is throwing the exception
• Server certs need to be readable by user and group manageiq-appliance#365
• [WIP] make old certs readable by manageiq user manageiq-rpm_build#298

[Fryguy]

Fixed in ManageIQ/manageiq-ui-classic#8919