File permission regression in v25.3: Lumberjack upgrade modified operator log permission

[sachu-thomas7]

Problem

After upgrading to Vertica operator v25.3, log files are created with restrictive 600 permissions instead of 644, preventing sidecar containers from reading log files for external log processing.

Root Cause

The lumberjack library upgrade from v2.0.0 to v2.2.1 in commit 7f7bb7aa changed default file permissions as a security
enhancement.

Lumberjack library change:
diff

• mode := os.FileMode(0644) // v2.0.0 - readable by group/others

• mode := os.FileMode(0600) // v2.2.1 - owner-only access

Reference: natefinch/lumberjack@v2.0.0...v2.2.1

Impact

This breaks deployments using sidecar containers to read Vertica log files and forward them to centralized logging systems (ELK, Splunk, monitoring platforms).

Use Case

Common Kubernetes pattern where sidecar containers with shared volumes read /logs/vertica.log to ship logs to external systems for centralized logging and monitoring.

Current Behavior

# v25.3 creates files with restrictive permissions
-rw------- 1 65532 65532 vertica.log  # Only owner can read       

Expected Behavior

# v24.x behavior - allows sidecar access
-rw-r--r-- 1 65532 65532 vertica.log  # Group/others can read

Workaround Applied

Modified operator container deployment to use same UID as sidecar container:

securityContext:
  runAsUser: 123456    # Match sidecar UID                                                                                                                                                                                      
  runAsGroup: 123456   # Match sidecar GID       

Request

Please consider providing a configuration option to control log file permissions or restore the previous 644 permissions to maintain compatibility with sidecar-based log shipping patterns

[cchen-vertica]

We will plan this feature soon.

[roypaulin]

@sachu-thomas7 should I assume that by vertica.log you actually mean the operator log file ? And that the mentioned sidecar is in the operator pod? Am I right?

[sachu-thomas7]

Hello @cchen-vertica ,
It is fine by me that you consider this as feature but please do not keep this away for longer period.

Hello @roypaulin ,
Yes, the vertica.log is the operator log file and the sidecar container is running in the operator pod.

[roypaulin]

Got you ! Will take a look asap!

[roypaulin]

I have a fix but before I have some questions :

Workaround Applied
Modified operator container deployment to use same UID as sidecar container:
securityContext:
runAsUser: 123456 # Match sidecar UID
runAsGroup: 123456 # Match sidecar GID

I don't get this workaround. By default, the operator and sidecars have the same user and group (from securityContext variable in helm, and you can enforce it using that helm variable). Why would you need to modify the operator container deployment?

[roypaulin]

In your case, do you need the operator and sidecar to have different user/group? If that's not the case, then the current solution should work for you.

Trying to understand your use case.

[sachu-thomas7]

Hello @roypaulin ,
sorry for the delay in response.
Yes, we want to have different user/group for the operator and sidecar as the sidecar is an 2pp and operator is provided your end.