[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-dev
Subject:    More on Windows/jetty
From:       "Rod Widdowson" <rdw () steadingsoftware ! com>
Date:       2018-09-13 15:46:55
Message-ID: 002301d44b78$ffa773f0$fef65bd0$ () steadingsoftware ! com
[Download RAW message or body]

(I hope that this only gets delivered only once, Outlook took a fit with my last mail \
to this list, my apologies.  I have applied some fixes locally)

When I was getting the windows installer for Jetty9.4/IdP3.4 I discovered that to \
make progress I have to avoid forking jetty. Last week I took an action item to \
investigate what the root causes were.

To that end I opened IDP-1326 to act as a log of all I found; it makes for \
interesting reading but it is full of needless details.

The key findings are:

1)  Forking inside jetty does not do anything sensible about inheriting the security \
state of the forking process.  This impacts if you start from an elevated prompt \
(because the child runs unelevated).  Starting from a fully privileged account seems \
to do the right thing.  This makes sense in terms of "If you didn't know to do \
something special this is the result you'd get".

2) Forking inside jetty selectively destroys the setting of (some) inherited \
variables.  This affects us because we want to set idp.home and setting it to

	-Didp.home=C:/Program Files (x86)/Shibboleth/IdP
	
     Results in the forked process being given

	[7]: "-Didp.home=C:/Program\ Files\ (x86)/Shibboleth/IdP"

     Which doesn't end well when we try to open our configuration

3) If you set the property in the system environment you can get further.  But better \
be sure to avoid native directory delimiters ('\').  If you use them, then we fail in \
Spring 

	Caused by: java.io.FileNotFoundException: C:\Program Files \
(x86)\Shibboleth\IdP\system\conf\conditional:C:\Program Files \
(x86)\Shibboleth\IdP\conf\admin\unlock-keys.xml (The filename, directory name, or \
volume label syntax is incorrect)

      I haven't bothered to chase up why this happens, but it doesn't surprise me.

The bottom line remains the same - do not fork on windows.  If you do fork,  do not \
expect to be able to pass anything sensible down via environment variables.

I don't really feel like taking this any further.  I could dig to the bottom of (3) \
if people wanted and I suppose I might just about be able to pull together a PR to \
fix (2) - or better still write something such that the output of --dry-run could be \
sensible fed into procrun, which is their documented way to run jetty as a daemon.

Thoughts?

/Rod

-- 
To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net


[prev in list] [next in list] [prev in thread] [next in thread]