adding a forced run_user assignment to launch.script

[psytester]

The launch.script should be enhanced to be more security robust
spring-boot-project/spring-boot-tools/spring-boot-loader-tools/src/main/resources/org/springframework/boot/loader/tools/launch.script

The launch.script extracts the run_user in line 129 by the file owner run_user=$(ls -ld "$jarfile" | awk '{print $3}')

But it should be possible to explicitly give the launch.script a RUN_AS=user, no matter who owns the file.

This prevents the following misconfigurations, which will currently cause the process to start as root.

1. if no chown has been made to the embedded "JAR" file, in the worst case it might belong to the root user.
2. or a tarball was unpacked and on the build system was the target owner's uid 1010, on the production system is the uid = 1035
   id: ‘1010’: no such user

With the desired extension it would then be able to force the launcher to use the target user, no matter what the file system says.

Sysadmins are humans and making faults at installation ;-)

[koziolk]

@psytester Passing RUN_AS=user parameter should be required or optional?

[psytester]

It depends on whether the security by design is a key feature of spring-boot or not. ;-)
For me I would prefer to force it as required from security point of view.
It would be great to make it clear to the operator under which account the service runs by means of this mandatory parameter. They have to think about twice. If someone decides to set RUN_AS=root, they are already lost.
Re-owning the file to a desired user is more error prone. The RUN_AS=user is done in systemd or init.d once and it's fine for ages.

[wagnerluis1982]

Hi, I'm looking forward to make a contribution to Spring and this issue seems a good start point.

Focusing on the issue, I see it as a very very simple change with, probably, little impact.

I only don't know yet about tests, can someone point me to where are defined tests for the launch script?

[philwebb]

Hi @wagnerluis1982,

Thanks very much for offering to pick this one up. The launch script is unfortunately a little harder to test than the Java code. We have a series of integration tests here. Probably SysVinitLaunchScriptIT is the one you want to look at.

Don't worry too much if you can't get to the tests, we can always add some ourselves before we merge.

[wagnerluis1982]

Hi @philwebb,

Thanks. You may assign to myself this issue. I hope to have some code until weekend.

[wagnerluis1982]

Hi, about the RUN_AS behavior, I have the following question:

1. If I set this option on my conf and the calling user is not root, what would be better?
   a. Raise an error?
   b. Run normally, ignore the option?

I, personally, prefer (a), but I wanted to hear your opinions.

[philwebb]

My preference would be to fail hard since it's probably a configuration error.

[wagnerluis1982]

Hi @philwebb,

By "fail hard" you mean let the start-stop-daemon fail when try to change UID (--chuid)?

Or you mean to handle the error early?

[philwebb]

I'm not sure really. I just meant that ignoring the error and running normally isn't a good option. It looks like we try to use run_user before calling start-stop-daemon so I guess failing early would probably be the best option.

[wagnerluis1982]

@philwebb I got and I agree, thanks!

[philwebb]

Closing in favor of PR #16973