Re: [Wrapper-user] Problem with RUN_AS_USER and nologin-shell

[O.Pax <o....@we...>]

Hello,

I agree the use of launchctl is the preferred way to use the wrapper on
Mac OS X systems. This leaves the question of how the problem with
RUN_AS_USER users with restricted shells should be handled on other
platforms. As I wrote, on Linux systems, "su -s /bin/sh ..." can be
used. With OS X out of the mix, we do not need to care about
compatibility there, but what about other supported UNIX variants? I
unfortunately do not have the means to test it myself.

I still do think that it would be preferrable for the wrapper script to
fix the shell that is used to execute RUN_AS_USER commands. This not
only alleviates problems with restricted shells as in my original mail,
it also renders behavior of the wrapper script more deterministic.

Is there any chance you might consider this for a future version?

Thanks for your great work,
Opax

On 21.10.14 05:18, Alexandre Klein wrote:
> Hi,
> 
> Thank you for your message.
> 
> On Mac OS X, we should not use "sudo" or "su" to interact with a daemon.
> We should use "launchctl".
> In the current version of the script file, we are correctly using
> "launchctl" to install, start and remove the daemon.
> Unfortunately, we are using "su - $RUN_AS_USER ..." to stop the daemon,
> which is not correct.
> 
> In the next version of the Wrapper (3.5.26), we will fix this and use
> "launchctl stop". By doing so, this will avoid the issue described by Opax.
> 
> If you have any comments or suggestions, please don't hesitate to
> contact us via our mailing list or directly via our support email
> su...@ta... <mailto:su...@ta...>
> 
> Regards,
> Alexandre Klein
> 
> On Mon, Oct 20, 2014 at 5:38 AM, Dannes Wessels <da...@ex...
> <mailto:da...@ex...>> wrote:
> 
>     Hi,
> 
>>     On 11 Oct 2014, at 0:27 , o....@we... <mailto:o....@we...> wrote:
>>
>>     I noticed that the checkUser function uses "su - $RUN_AS_USER -c
>>     ..." to switch to the target user. This fails if that user does
>>     not have a valid login shell, e.g. /bin/false or
>>     /usr/sbin/nologin. On the other hand, such "shells" are usually
>>     the default for daemon accounts in many UNIX systems. For
>>     GNU/Linux, this is easily fixed by using "su -s /bin/sh",
>>     overriding the user's default shell. Unfortunately, OS X's su does
>>     not have this option, so this is not a portable solution.
>>
>>     The only portable way I found to circumvent the problem is to use
>>     "sudo -u $RUN_AS_USER ...", but I do not know whether this may
>>     cause problems on some systems/configurations.
>>
>>     I think it would be nice to be able to use such restricted system
>>     accounts for Java services, so what do you think would be the best
>>     solution? Using the "-s" switch on systems that support it and
>>     ignore the problem on others? Or fall back to sudo on systems
>>     where the switch is missing?
> 
>     I can not think of a good work around either, I hope some one can…….
> 
>     regards
> 
>     Dannes
>