log/server.log root owner issue

[maylann....@gmail.com]

Hello

I have a pretty strange issue when I am running builds on our Jenkins Linux server.

Our projects are being build in a docker container running as a Jenkins user and NOT as root. 

So the Java project is a jdk 11 maven project and we are using cargo 1.9.11 for spinning up a wildfly container for integration tests. The projcets builds ok and succeeds on the first build, however next time it is building on Jenkins using the Jenkins user it fails to clean the target folder the Jenkins user is not allowed to delete directories and files owned by root. And in some way even though the docker container is run by the Jenkins user and group it creates a /log/server.log file with group and user owners as root in the target folder. See below marked with yellow:

ls -al target/cargo/installs/wildfly-26.0.1.Final/wildfly-26.0.1.Final/standalone/

total 4
drwxr-xr-x.  7 jenkins jenkins   79 May 30 13:39 .
drwxr-xr-x. 11 jenkins jenkins  239 May 30 13:38 ..
drwxr-xr-x.  2 jenkins jenkins 4096 May 30 13:38 configuration
drwxr-xr-x.  2 jenkins jenkins   24 May 30 13:38 deployments
drwxr-xr-x.  3 jenkins jenkins   17 May 30 13:38 lib
drwxr-xr-x.  2 root    root      24 May 30 13:39 log
drwxr-xr-x.  3 jenkins jenkins   18 May 30 13:38 tmp

ls -al target/cargo/installs/wildfly-26.0.1.Final/wildfly-26.0.1.Final/standalone/log

-rw-r--r--. 1 root    root    182 May 29 23:38 server.log

cat target/cargo/installs/wildfly-26.0.1.Final/wildfly-26.0.1.Final/standalone/log/server.log
2022-05-29 23:38:18,428 INFO  [org.jboss.modules] (main) JBoss Modules version 2.0.0.Final
2022-05-29 23:38:20,213 INFO  [org.jboss.modules] (main) JBoss Modules version 2.0.0.Final

We only have the issue for this 1 directory and file...

This asn't been an issue for us before, but we have recently upgraded to wildfly 26 where this issue started occuring. Any idea why this log folder in some way is created with root as owner. I didn't even think it was possible when the running docker container is run by jenkins:jenkins:

docker run -t -d -u jenkins:jenkins ...

Best regards 

Kasper

[S. Ali Tokmen]

Hi Kasper

That is for sure quite unexpected!

Does your upgraded Fedora by any chance has some automated capabilities around logging, either from a security perspective (i.e., updating access rights) or for centralizing? You could try that out by "manually" creating a similar structure (a folder called log with a .log file in it), and see what happens.

Regards

S. Ali Tokmen
https://ali.tokmen.com/
https://contact.ali.tokmen.com/

--
You received this message because you are subscribed to the Google Groups "Codehaus Cargo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-carg...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/83a03ac8-e450-4d1a-801b-583fb0f5c0afn%40googlegroups.com.

[maylann....@gmail.com]

Thanks for your reply Ali.

Sadly no I am not able to reproduce it manually. Also tried starting the same docker container interactively and both creating a directory and file in there, but that does get the correct owner and user - as all the other files does, except that one /log dir and server.log file in it... Creating the log/server.log also doesn't change any access rights other than the user that I am doing it with. I don't get where to root:root is comming from :-(

/Kasper

[S. Ali Tokmen]

Hi Kasper

Perhaps to try to replicate, could you provide details about your Jenkins server, i.e. which OS it has, version, and the output of the mvn -version command.

Otherwise, an "ugly" workaround remains to run sudo chown commands in Jenkins, before the build is kicked in.

Regards

S. Ali Tokmen
https://ali.tokmen.com/
https://contact.ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/8b2a04e9-7a1a-4d7b-9de9-36d676690d4an%40googlegroups.com.