Re: System properties: JVM launch versus catalina.properties

[Romain Manni-Bucau]

except the name, if run in the same JVM thantomcat it is too late anyway

so 2 options are either to not do it or preprocess it IMHO

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le sam. 29 déc. 2018 à 13:25, Martin Grigorov  a
écrit :

> Hi Igal,
>
> I am not sure this is a good idea.
> Usually .properties.default files are used as sample files. And one has to
> rename them to .properties to make use of them.
> IMO your suggestion will be confusing for people used to this approach.
>
> Regards,
> Martin
>
> On Sat, Dec 29, 2018 at 2:11 AM Igal Sapir  wrote:
>
> > Chris,
> >
> > On 12/28/2018 7:07 AM, Christopher Schultz wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > All,
> > >
> > > Someone asked this question on SO recently:
> > >
> https://stackoverflow.com/questions/53921375/tomcat-overriding-catalina-
> > > properties-from-commandline/53952396#53952396
> > >
> > > TLDR: this person wants to set system properties in
> > > catalina.properties but be able to "override" those from the
> command-lin
> > > e.
> > >
> > > The fix would be trivial: just don't clobber the value of any existing
> > > system property in CatalinaProperties when copying the properties from
> > > the file to the live system properties.
> > >
> > > I'm wondering if anyone can think of any security issues with doing
> > > that. Presumably, if a user can launch Tomcat, they can set system
> > > properties. However, it's possible that a user might have the right to
> > > *launch* Tomcat, but not reconfigure it (e.g. read-only
> > > catalina.properties).
> > >
> > > That could easily be solved by using a catalina.properties-only
> > > setting like "catalina.properties.noclobber.system.properties=true" or
> > > something like that.
> >
> > How about adding an optional file named "catalina.properties.default",
> > which will be read before "catalina.properties", and whose values will
> > be set only if no corresponding keys are set in System properties?  e.g.
> >
> > # file catalina.properties.default
> > tomcat.port=8080
> >
> > Can be overridden with `-Dtomcat.properties=`, but
> >
> > # file catalina.properties
> > tomcat.host=localhost
> >
> > Can not be overridden, as it is now.
> >
> > Users will know that if they place a value in the default file, it could
> > be overridden with a System property.
> >
> > This should be fairly simple and I can implement it if it sounds like a
> > good idea.
> >
> > Igal
> >
> >
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>

Re: System properties: JVM launch versus catalina.properties

[Martin Grigorov]

Hi Igal,

I am not sure this is a good idea.
Usually .properties.default files are used as sample files. And one has to
rename them to .properties to make use of them.
IMO your suggestion will be confusing for people used to this approach.

Regards,
Martin

On Sat, Dec 29, 2018 at 2:11 AM Igal Sapir  wrote:

> Chris,
>
> On 12/28/2018 7:07 AM, Christopher Schultz wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > All,
> >
> > Someone asked this question on SO recently:
> > https://stackoverflow.com/questions/53921375/tomcat-overriding-catalina-
> > properties-from-commandline/53952396#53952396
> >
> > TLDR: this person wants to set system properties in
> > catalina.properties but be able to "override" those from the command-lin
> > e.
> >
> > The fix would be trivial: just don't clobber the value of any existing
> > system property in CatalinaProperties when copying the properties from
> > the file to the live system properties.
> >
> > I'm wondering if anyone can think of any security issues with doing
> > that. Presumably, if a user can launch Tomcat, they can set system
> > properties. However, it's possible that a user might have the right to
> > *launch* Tomcat, but not reconfigure it (e.g. read-only
> > catalina.properties).
> >
> > That could easily be solved by using a catalina.properties-only
> > setting like "catalina.properties.noclobber.system.properties=true" or
> > something like that.
>
> How about adding an optional file named "catalina.properties.default",
> which will be read before "catalina.properties", and whose values will
> be set only if no corresponding keys are set in System properties?  e.g.
>
> # file catalina.properties.default
> tomcat.port=8080
>
> Can be overridden with `-Dtomcat.properties=`, but
>
> # file catalina.properties
> tomcat.host=localhost
>
> Can not be overridden, as it is now.
>
> Users will know that if they place a value in the default file, it could
> be overridden with a System property.
>
> This should be fairly simple and I can implement it if it sounds like a
> good idea.
>
> Igal
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: System properties: JVM launch versus catalina.properties

[Igal Sapir]

Chris,

On 12/28/2018 7:07 AM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Someone asked this question on SO recently:
https://stackoverflow.com/questions/53921375/tomcat-overriding-catalina-
properties-from-commandline/53952396#53952396

TLDR: this person wants to set system properties in
catalina.properties but be able to "override" those from the command-lin
e.

The fix would be trivial: just don't clobber the value of any existing
system property in CatalinaProperties when copying the properties from
the file to the live system properties.

I'm wondering if anyone can think of any security issues with doing
that. Presumably, if a user can launch Tomcat, they can set system
properties. However, it's possible that a user might have the right to
*launch* Tomcat, but not reconfigure it (e.g. read-only
catalina.properties).

That could easily be solved by using a catalina.properties-only
setting like "catalina.properties.noclobber.system.properties=true" or
something like that.


How about adding an optional file named "catalina.properties.default", 
which will be read before "catalina.properties", and whose values will 
be set only if no corresponding keys are set in System properties?  e.g.


# file catalina.properties.default
tomcat.port=8080

Can be overridden with `-Dtomcat.properties=`, but

# file catalina.properties
tomcat.host=localhost

Can not be overridden, as it is now.

Users will know that if they place a value in the default file, it could 
be overridden with a System property.


This should be fairly simple and I can implement it if it sounds like a 
good idea.


Igal








-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: System properties: JVM launch versus catalina.properties

[Romain Manni-Bucau]

Except if you call java -jar catalina_home/lib/prdtartup.jar which creates
a temp file used instead of setenv (just a generator) so you can read it in
plain java and launch tomcat only later to ensure it respects all props.
This small main would do anything except suceed or fail.


Le ven. 28 déc. 2018 19:41, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Romain,
>
> On 12/28/18 10:10, Romain Manni-Bucau wrote:
> > Hi
> >
> > As a user it is nicer to be able to set all system properties in
> > the same place and catalina code is too late for some of them like
> > log manager. Why not having a conf/system.properties handled by
> > scripts and in fallback by Tomcat (embedded case)? Would just be a
> > more natural way to write it than setenv.
>
> Shell-script processing of .properties files will likely be hairy.
>
> I have seen systems like install4j which use "vmoptions" files which
> essentially allow you to set system properties without actually typing
> a huge line of text with "-Dkey=value" but instead have "key=value" on
> separate lines. I suspect they do not adhere to the full "properties"
> specification (e.g. ignorable whitespace, line-continuation, \u
> character processing, etc.).
>
> It we defined something that "wasn't a properties file, but looks like
> a properties file", then maybe it would be okay. It could be processed
> easily like this on systems with proper scripting capabilities:
>
> sysprops=$( echo $( sed -e 's/^/"-D/' -e 's/$/"/'
> conf/system.not-properties $) $)
>
> ...
>
> java [script properties] $sysprops
>
> You still have the awful problem of quoting, though.
>
> - -chris
>
> > Le 28 déc. 2018 16:07, "Christopher Schultz"
> >  a écrit :
> >
> > All,
> >
> > Someone asked this question on SO recently:
> > https://stackoverflow.com/questions/53921375/tomcat-overriding-catalin
> a-
> >
> >
> properties-from-commandline/53952396#53952396
> >  na-properties-from-commandline/53952396#53952396
> 
> >
> >
> >  TLDR: this person wants to set system properties in
> > catalina.properties but be able to "override" those from the
> > command-lin e.
> >
> > The fix would be trivial: just don't clobber the value of any
> > existing system property in CatalinaProperties when copying the
> > properties from the file to the live system properties.
> >
> > I'm wondering if anyone can think of any security issues with
> > doing that. Presumably, if a user can launch Tomcat, they can set
> > system properties. However, it's possible that a user might have
> > the right to *launch* Tomcat, but not reconfigure it (e.g.
> > read-only catalina.properties).
> >
> > That could easily be solved by using a catalina.properties-only
> > setting like "catalina.properties.noclobber.system.properties=true"
> > or something like that.
> >
> > What does everyone think?
> >
> > Thanks, -chris
> >
> > -
> >
> >
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwmblsACgkQHPApP6U8
> pFj/0RAAt+e4UDhtWZ7bHLGfNkXEAiO0hAor8MOHINn8f99Aeu9LbD0odH9ruDzy
> B0s3Yhyg49PgUIxZbqqCPFMME83L/Fx//YT2VRfgvxjM3BvWCtGIRAqx8NZpbbqX
> fbQYxdc7DWkIr3/5CQ3BsVPZu9HdhmoOTeFMMPvRWbW4LqRfkQXyNdAd308i2a6M
> 0N0RQED7gyEAPfMKaXOLX+AoSApAnGG7F4c+jr8l6P8U0VVRnX+TFWrjBmEt2iWx
> z0dtH0AZJlf2QwEq48g1qSaB7vUo9w9WPx57YYB3Zv1kcGPGF1h6Acy7S3vqEVgo
> ZafsK5PzyVycXd37P5EcQ1Yh1yELVS0Zdl3qfGxllX6jDSpb6cMcMUbC6buMpPwG
> Af6WmUCfDThI7Q9Om5MttT73acj/Wcvh1rtYbu6hhjPXZ+uplGJcwBcY1sujC81S
> s389xDL+GVxde31sW6pSVY+OYsdrg1HsqQJeFnmpEDZSjrSgTEsS6hj0dVRkIPCS
> 0k1JPydMD28OGwdoxLIQHYNq9q3uneBDrw+VTcu1Q9RIJcQ5NW8ksoY/GHbYfG18
> lf01sFu28RyAM1kVZYMc2IZlq61opW4w/DPTGChgNpxqx7yD5nfm31lqvAsYKyht
> EXKqCRayn+89KEV3px0UbAeSVQWVD96a12KbYZHF1IEm/eO+a2M=
> =Qoxt
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: System properties: JVM launch versus catalina.properties

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Romain,

On 12/28/18 10:10, Romain Manni-Bucau wrote:
> Hi
> 
> As a user it is nicer to be able to set all system properties in
> the same place and catalina code is too late for some of them like
> log manager. Why not having a conf/system.properties handled by
> scripts and in fallback by Tomcat (embedded case)? Would just be a
> more natural way to write it than setenv.

Shell-script processing of .properties files will likely be hairy.

I have seen systems like install4j which use "vmoptions" files which
essentially allow you to set system properties without actually typing
a huge line of text with "-Dkey=value" but instead have "key=value" on
separate lines. I suspect they do not adhere to the full "properties"
specification (e.g. ignorable whitespace, line-continuation, \u
character processing, etc.).

It we defined something that "wasn't a properties file, but looks like
a properties file", then maybe it would be okay. It could be processed
easily like this on systems with proper scripting capabilities:

sysprops=$( echo $( sed -e 's/^/"-D/' -e 's/$/"/'
conf/system.not-properties $) $)

...

java [script properties] $sysprops

You still have the awful problem of quoting, though.

- -chris

> Le 28 déc. 2018 16:07, "Christopher Schultz"
>  a écrit :
> 
> All,
> 
> Someone asked this question on SO recently: 
> https://stackoverflow.com/questions/53921375/tomcat-overriding-catalin
a-
>
> 
properties-from-commandline/53952396#53952396
> 
>
>  TLDR: this person wants to set system properties in 
> catalina.properties but be able to "override" those from the
> command-lin e.
> 
> The fix would be trivial: just don't clobber the value of any
> existing system property in CatalinaProperties when copying the
> properties from the file to the live system properties.
> 
> I'm wondering if anyone can think of any security issues with
> doing that. Presumably, if a user can launch Tomcat, they can set
> system properties. However, it's possible that a user might have
> the right to *launch* Tomcat, but not reconfigure it (e.g.
> read-only catalina.properties).
> 
> That could easily be solved by using a catalina.properties-only 
> setting like "catalina.properties.noclobber.system.properties=true"
> or something like that.
> 
> What does everyone think?
> 
> Thanks, -chris
> 
> -
>
> 
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwmblsACgkQHPApP6U8
pFj/0RAAt+e4UDhtWZ7bHLGfNkXEAiO0hAor8MOHINn8f99Aeu9LbD0odH9ruDzy
B0s3Yhyg49PgUIxZbqqCPFMME83L/Fx//YT2VRfgvxjM3BvWCtGIRAqx8NZpbbqX
fbQYxdc7DWkIr3/5CQ3BsVPZu9HdhmoOTeFMMPvRWbW4LqRfkQXyNdAd308i2a6M
0N0RQED7gyEAPfMKaXOLX+AoSApAnGG7F4c+jr8l6P8U0VVRnX+TFWrjBmEt2iWx
z0dtH0AZJlf2QwEq48g1qSaB7vUo9w9WPx57YYB3Zv1kcGPGF1h6Acy7S3vqEVgo
ZafsK5PzyVycXd37P5EcQ1Yh1yELVS0Zdl3qfGxllX6jDSpb6cMcMUbC6buMpPwG
Af6WmUCfDThI7Q9Om5MttT73acj/Wcvh1rtYbu6hhjPXZ+uplGJcwBcY1sujC81S
s389xDL+GVxde31sW6pSVY+OYsdrg1HsqQJeFnmpEDZSjrSgTEsS6hj0dVRkIPCS
0k1JPydMD28OGwdoxLIQHYNq9q3uneBDrw+VTcu1Q9RIJcQ5NW8ksoY/GHbYfG18
lf01sFu28RyAM1kVZYMc2IZlq61opW4w/DPTGChgNpxqx7yD5nfm31lqvAsYKyht
EXKqCRayn+89KEV3px0UbAeSVQWVD96a12KbYZHF1IEm/eO+a2M=
=Qoxt
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: System properties: JVM launch versus catalina.properties

[Romain Manni-Bucau]

Hi

As a user it is nicer to be able to set all system properties in the same
place and catalina code is too late for some of them like log manager. Why
not having a conf/system.properties handled by scripts and in fallback by
Tomcat (embedded case)? Would just be a more natural way to write it than
setenv.

Le 28 déc. 2018 16:07, "Christopher Schultz" 
a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Someone asked this question on SO recently:
https://stackoverflow.com/questions/53921375/tomcat-overriding-catalina-
properties-from-commandline/53952396#53952396


TLDR: this person wants to set system properties in
catalina.properties but be able to "override" those from the command-lin
e.

The fix would be trivial: just don't clobber the value of any existing
system property in CatalinaProperties when copying the properties from
the file to the live system properties.

I'm wondering if anyone can think of any security issues with doing
that. Presumably, if a user can launch Tomcat, they can set system
properties. However, it's possible that a user might have the right to
*launch* Tomcat, but not reconfigure it (e.g. read-only
catalina.properties).

That could easily be solved by using a catalina.properties-only
setting like "catalina.properties.noclobber.system.properties=true" or
something like that.

What does everyone think?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwmPCQACgkQHPApP6U8
pFgmzRAAnIzALW5ugkGrQl9uHYBz/WrNXISiSc4aqCXzqzlmDAGENO4coRzTe88n
0uFWLVbjembgz78Cbs1+AdjuGxwpMhPb+mWysAB/Rq7iosr00eXOrV64prHjRhCU
pV00Om943PuxegLFQ/O4WW5grWyUUUm7mWBbyadAbs6ZOspnozS9DJnCwxIwTQgz
JY3kRhZq7+lEirtKBdjtbyaDdVn9BXy59wgXa4e6AQ7ESN41S3NM+9AMhFfTP9Ly
12s/Vb9WQa5hpQsJqVUVoHmDYSI3bQs++7LWTr3fIR7+829A8rTvYS4rxvWhUE3O
dXZFHWU4ATU49kCHG0zHpsDBgU4bL611nsh2yJiVj0uGL/+DxjM0B8Z4Cf+XbltL
wXaraK2oh1SQwo6NqzhW/b5MxzVr7aiX1fuM5hOEZfgbTROnTRnP/uEVVnh5q16v
LPY0SSdJJhLcuxQR8m3ZaFaWik3kZ7SCAq3Mt/jFMjVvmhHQ13WWmrHtiDaYhd1l
Eoi9iGS6AHTr66opoqSfYbviRT2fiRRnwmzXXuFX3U9X7gXhUp44CPqiNODtma22
xPNgDKyuWYByILGRigG/B+Wb3Y2cUTCcuSvI3H/l5PoPi35mR24bmJvC8EWkD1HF
5knfa/ZBoGx48YuXnzVUWe95JAnmNrnj/qcdZ4/1ljxd76jCEGQ=
=qES3
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

System properties: JVM launch versus catalina.properties

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Someone asked this question on SO recently:
https://stackoverflow.com/questions/53921375/tomcat-overriding-catalina-
properties-from-commandline/53952396#53952396

TLDR: this person wants to set system properties in
catalina.properties but be able to "override" those from the command-lin
e.

The fix would be trivial: just don't clobber the value of any existing
system property in CatalinaProperties when copying the properties from
the file to the live system properties.

I'm wondering if anyone can think of any security issues with doing
that. Presumably, if a user can launch Tomcat, they can set system
properties. However, it's possible that a user might have the right to
*launch* Tomcat, but not reconfigure it (e.g. read-only
catalina.properties).

That could easily be solved by using a catalina.properties-only
setting like "catalina.properties.noclobber.system.properties=true" or
something like that.

What does everyone think?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwmPCQACgkQHPApP6U8
pFgmzRAAnIzALW5ugkGrQl9uHYBz/WrNXISiSc4aqCXzqzlmDAGENO4coRzTe88n
0uFWLVbjembgz78Cbs1+AdjuGxwpMhPb+mWysAB/Rq7iosr00eXOrV64prHjRhCU
pV00Om943PuxegLFQ/O4WW5grWyUUUm7mWBbyadAbs6ZOspnozS9DJnCwxIwTQgz
JY3kRhZq7+lEirtKBdjtbyaDdVn9BXy59wgXa4e6AQ7ESN41S3NM+9AMhFfTP9Ly
12s/Vb9WQa5hpQsJqVUVoHmDYSI3bQs++7LWTr3fIR7+829A8rTvYS4rxvWhUE3O
dXZFHWU4ATU49kCHG0zHpsDBgU4bL611nsh2yJiVj0uGL/+DxjM0B8Z4Cf+XbltL
wXaraK2oh1SQwo6NqzhW/b5MxzVr7aiX1fuM5hOEZfgbTROnTRnP/uEVVnh5q16v
LPY0SSdJJhLcuxQR8m3ZaFaWik3kZ7SCAq3Mt/jFMjVvmhHQ13WWmrHtiDaYhd1l
Eoi9iGS6AHTr66opoqSfYbviRT2fiRRnwmzXXuFX3U9X7gXhUp44CPqiNODtma22
xPNgDKyuWYByILGRigG/B+Wb3Y2cUTCcuSvI3H/l5PoPi35mR24bmJvC8EWkD1HF
5knfa/ZBoGx48YuXnzVUWe95JAnmNrnj/qcdZ4/1ljxd76jCEGQ=
=qES3
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org