You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jinmei Liao <ji...@pivotal.io> on 2017/08/03 05:15:01 UTC
behavior of "connect" command when --use-ssl
I am looking at a behavior of Gfsh's connect command using ssl. I am not
sure whether it's a valid use case or just some side effect of spaghetti
code.
So if SSL is configured on locator, and we need to connect to it in Gfsh
gfsh>connect --security-properties-file=ssl.properties
this will try to load the file for ssl configs, and use that for
connection, sounds good.
gfsh> connect --use-ssl
this will look for a gfSecurity.properties file in current location, home
dir, or classpath in order and use that for connection. But if that file
doesn't exist or empty, it will prompt for all the ssl info.
So when user issues "connect --use-ssl", sometimes they will get prompted,
sometimes not depending on whether this "special" file exists somewhere in
your environment. This just does not feel right. I am wondering if looking
for this "special" file really a good feature?
--
Cheers
Jinmei
Re: behavior of "connect" command when --use-ssl
Posted by Jared Stewart <js...@pivotal.io>.
+1 to excluding the home dir at the very least. I think that behavior is surprising, and it also makes it harder to maintain multiple separate, isolated versions of Geode on the same machine. (One can easily introduce an unintended properties file into their configuration simply by copying it into their home directory.)
- Jared
> On Aug 3, 2017, at 3:30 PM, John Blum <jb...@pivotal.io> wrote:
>
> Good question.
>
> +1 to... I also think specifying settings should be "explicit" rather than
> picking up arbitrary files in known locations (e.g. working dir, home dir,
> classpath, etc). This would be decidedly bad if an auth file were picked
> up that opened Geode up to the world, for instance.
>
> On Thu, Aug 3, 2017 at 3:25 PM, jiliao@pivotal.io <ma...@pivotal.io> <jiliao@pivotal.io <ma...@pivotal.io>> wrote:
>
>> Yeah, I noticed that too. It would be nice to have those other commands
>> NOT do these sort of things either. It is a change if behavior, but how
>> many users are using this behavior?
>>
>>
>>
>> -------- Original Message --------
>> Subject: Re: behavior of "connect" command when --use-ssl
>> From: John Blum
>> To: geode
>> CC:
>>
>>
>> Well, then `connect` will be inconsistent with other commands (e.g. `start
>> locator`) at best.
>>
>> Geode is going to pick up the gfSecurity.properties file in your HOME
>> directory whether you want it to or not, and especially regardless of the
>> options given to either `start locator` or `start server` since Geode looks
>> in well known locations (work dir, HOME dir and CLASSPATH) for both
>> gemfire.properties and gfSecurity.properties, by default.
>>
>> See here...
>>
>> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
>> core/src/main/java/org/apache/geode/distributed/internal/
>> DistributionConfigImpl.java#L864
>>
>> Then here...
>>
>> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
>> core/src/main/java/org/apache/geode/distributed/
>> DistributedSystem.java#L687
>>
>> And finally, here...
>>
>> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
>> core/src/main/java/org/apache/geode/distributed/
>> DistributedSystem.java#L690-L710
>>
>> This...
>>
>> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
>> core/src/main/java/org/apache/geode/distributed/
>> DistributedSystem.java#L691-L693
>>
>> ... is going to looking working directory (of the running GemFire
>> process... Locator/Server, Manager)
>>
>> This...
>>
>> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
>> core/src/main/java/org/apache/geode/distributed/
>> DistributedSystem.java#L700-L702
>>
>> ... checks the user's HOME dir, and finally...
>>
>> This...
>>
>> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
>> core/src/main/java/org/apache/geode/distributed/
>> DistributedSystem.java#L709
>>
>> ... resorts to resolving the [gemfire|gfSecurity].properties files from
>> the
>> CLASSPATH.
>>
>>
>> I am not opposed to the `connect` command changing in how it deals with
>> SSL, but it should be...
>>
>> 1. Obvious to the user
>> 2. Consistent where it is not obvious.
>>
>> $0.02
>>
>> -John
>>
>>
>>
>> On Thu, Aug 3, 2017 at 2:24 PM, Jinmei Liao wrote:
>>
>>> I don't have any problem of having all the "security" info in another
>>> properties file, but the fact that it's still trying to load a property
>>> file even if the command did not say so explicitly. I might have such a
>>> file sitting in my home dir for some occasions, but I may not want to use
>>> it in this command. If I do want it to load a gfSecurity.properties, I
>>> would have just issued "connect
>>> --security-properties-file=gfSecurity.properties" instead. This feature
>> is
>>> there just to, in my opinion, save user a few key strokes in typing out
>> the
>>> command, but it can cause a lot of unnecessary confusion and
>> implementation
>>> hassle.
>>>
>>>
>>> On Thu, Aug 3, 2017 at 9:46 AM, Kirk Lund wrote:
>>>
>>>> Historically, gfSecurity.properties is a companion to
>> gemfire.properties
>>> in
>>>> which sensitive key/value pairs can be kept in. The log banner does not
>>> (or
>>>> did not) log any values in gfSecurity.properties. Users would also
>>>> typically protect gfSecurity.properties with tighter permissions than
>>>> gemfire.properties.
>>>>
>>>> At the same time SecurityLogWriter was introduced to the APIs (Cache,
>>>> DistributedSystem). The idea behind this was that all security related
>>> log
>>>> statements would go to a special log file with tighter permissions.
>>>>
>>>> I would prefer not having either gfSecurity.properties or
>>>> SecurityLogWriter.
>>>> Now that we use Log4J2 for logging, it would be pretty straightforward
>> to
>>>> configure "security" loggers to log to a special log file without
>> having
>>> a
>>>> dedicated SecurityLogWriter. As for gfSecurity.properties, we already
>>>> redact all security related values from logging, so the only value of
>>>> having it is that Users who have permissions to read gemfire.properties
>>> can
>>>> be blocked from viewing the contents of gfSecurity.properties. I don't
>>> know
>>>> if this is useful or still a requirement for existing Users or not.
>>>>
>>>> I think another purpose for gfSecurity.properties was to avoid having
>>>> system properties such as -Dmy.password=foo from showing up in the list
>>> of
>>>> Java processes when using a command such as ps. There must be a better
>>> way
>>>> to protect against exposing sensitive configuration values.
>>>>
>>>> On Wed, Aug 2, 2017 at 10:15 PM, Jinmei Liao wrote:
>>>>
>>>>> I am looking at a behavior of Gfsh's connect command using ssl. I am
>>> not
>>>>> sure whether it's a valid use case or just some side effect of
>>> spaghetti
>>>>> code.
>>>>>
>>>>> So if SSL is configured on locator, and we need to connect to it in
>>> Gfsh
>>>>> gfsh>connect --security-properties-file=ssl.properties
>>>>> this will try to load the file for ssl configs, and use that for
>>>>> connection, sounds good.
>>>>>
>>>>> gfsh> connect --use-ssl
>>>>> this will look for a gfSecurity.properties file in current location,
>>> home
>>>>> dir, or classpath in order and use that for connection. But if that
>>> file
>>>>> doesn't exist or empty, it will prompt for all the ssl info.
>>>>>
>>>>> So when user issues "connect --use-ssl", sometimes they will get
>>>> prompted,
>>>>> sometimes not depending on whether this "special" file exists
>> somewhere
>>>> in
>>>>> your environment. This just does not feel right. I am wondering if
>>>> looking
>>>>> for this "special" file really a good feature?
>>>>>
>>>>> --
>>>>> Cheers
>>>>>
>>>>> Jinmei
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers
>>>
>>> Jinmei
>>>
>>
>>
>>
>> --
>> -John
>> john.blum10101 (skype)
>>
>>
>
>
> --
> -John
> john.blum10101 (skype)
Re: behavior of "connect" command when --use-ssl
Posted by John Blum <jb...@pivotal.io>.
Good question.
+1 to... I also think specifying settings should be "explicit" rather than
picking up arbitrary files in known locations (e.g. working dir, home dir,
classpath, etc). This would be decidedly bad if an auth file were picked
up that opened Geode up to the world, for instance.
On Thu, Aug 3, 2017 at 3:25 PM, jiliao@pivotal.io <ji...@pivotal.io> wrote:
> Yeah, I noticed that too. It would be nice to have those other commands
> NOT do these sort of things either. It is a change if behavior, but how
> many users are using this behavior?
>
>
>
> -------- Original Message --------
> Subject: Re: behavior of "connect" command when --use-ssl
> From: John Blum
> To: geode
> CC:
>
>
> Well, then `connect` will be inconsistent with other commands (e.g. `start
> locator`) at best.
>
> Geode is going to pick up the gfSecurity.properties file in your HOME
> directory whether you want it to or not, and especially regardless of the
> options given to either `start locator` or `start server` since Geode looks
> in well known locations (work dir, HOME dir and CLASSPATH) for both
> gemfire.properties and gfSecurity.properties, by default.
>
> See here...
>
> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
> core/src/main/java/org/apache/geode/distributed/internal/
> DistributionConfigImpl.java#L864
>
> Then here...
>
> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
> core/src/main/java/org/apache/geode/distributed/
> DistributedSystem.java#L687
>
> And finally, here...
>
> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
> core/src/main/java/org/apache/geode/distributed/
> DistributedSystem.java#L690-L710
>
> This...
>
> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
> core/src/main/java/org/apache/geode/distributed/
> DistributedSystem.java#L691-L693
>
> ... is going to looking working directory (of the running GemFire
> process... Locator/Server, Manager)
>
> This...
>
> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
> core/src/main/java/org/apache/geode/distributed/
> DistributedSystem.java#L700-L702
>
> ... checks the user's HOME dir, and finally...
>
> This...
>
> https://github.com/apache/geode/blob/rel/v1.2.0/geode-
> core/src/main/java/org/apache/geode/distributed/
> DistributedSystem.java#L709
>
> ... resorts to resolving the [gemfire|gfSecurity].properties files from
> the
> CLASSPATH.
>
>
> I am not opposed to the `connect` command changing in how it deals with
> SSL, but it should be...
>
> 1. Obvious to the user
> 2. Consistent where it is not obvious.
>
> $0.02
>
> -John
>
>
>
> On Thu, Aug 3, 2017 at 2:24 PM, Jinmei Liao wrote:
>
> > I don't have any problem of having all the "security" info in another
> > properties file, but the fact that it's still trying to load a property
> > file even if the command did not say so explicitly. I might have such a
> > file sitting in my home dir for some occasions, but I may not want to use
> > it in this command. If I do want it to load a gfSecurity.properties, I
> > would have just issued "connect
> > --security-properties-file=gfSecurity.properties" instead. This feature
> is
> > there just to, in my opinion, save user a few key strokes in typing out
> the
> > command, but it can cause a lot of unnecessary confusion and
> implementation
> > hassle.
> >
> >
> > On Thu, Aug 3, 2017 at 9:46 AM, Kirk Lund wrote:
> >
> > > Historically, gfSecurity.properties is a companion to
> gemfire.properties
> > in
> > > which sensitive key/value pairs can be kept in. The log banner does not
> > (or
> > > did not) log any values in gfSecurity.properties. Users would also
> > > typically protect gfSecurity.properties with tighter permissions than
> > > gemfire.properties.
> > >
> > > At the same time SecurityLogWriter was introduced to the APIs (Cache,
> > > DistributedSystem). The idea behind this was that all security related
> > log
> > > statements would go to a special log file with tighter permissions.
> > >
> > > I would prefer not having either gfSecurity.properties or
> > > SecurityLogWriter.
> > > Now that we use Log4J2 for logging, it would be pretty straightforward
> to
> > > configure "security" loggers to log to a special log file without
> having
> > a
> > > dedicated SecurityLogWriter. As for gfSecurity.properties, we already
> > > redact all security related values from logging, so the only value of
> > > having it is that Users who have permissions to read gemfire.properties
> > can
> > > be blocked from viewing the contents of gfSecurity.properties. I don't
> > know
> > > if this is useful or still a requirement for existing Users or not.
> > >
> > > I think another purpose for gfSecurity.properties was to avoid having
> > > system properties such as -Dmy.password=foo from showing up in the list
> > of
> > > Java processes when using a command such as ps. There must be a better
> > way
> > > to protect against exposing sensitive configuration values.
> > >
> > > On Wed, Aug 2, 2017 at 10:15 PM, Jinmei Liao wrote:
> > >
> > > > I am looking at a behavior of Gfsh's connect command using ssl. I am
> > not
> > > > sure whether it's a valid use case or just some side effect of
> > spaghetti
> > > > code.
> > > >
> > > > So if SSL is configured on locator, and we need to connect to it in
> > Gfsh
> > > > gfsh>connect --security-properties-file=ssl.properties
> > > > this will try to load the file for ssl configs, and use that for
> > > > connection, sounds good.
> > > >
> > > > gfsh> connect --use-ssl
> > > > this will look for a gfSecurity.properties file in current location,
> > home
> > > > dir, or classpath in order and use that for connection. But if that
> > file
> > > > doesn't exist or empty, it will prompt for all the ssl info.
> > > >
> > > > So when user issues "connect --use-ssl", sometimes they will get
> > > prompted,
> > > > sometimes not depending on whether this "special" file exists
> somewhere
> > > in
> > > > your environment. This just does not feel right. I am wondering if
> > > looking
> > > > for this "special" file really a good feature?
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>
>
--
-John
john.blum10101 (skype)
Re: behavior of "connect" command when --use-ssl
Posted by John Blum <jb...@pivotal.io>.
Well, then `connect` will be inconsistent with other commands (e.g. `start
locator`) at best.
Geode is going to pick up the gfSecurity.properties file in your HOME
directory whether you want it to or not, and especially regardless of the
options given to either `start locator` or `start server` since Geode looks
in well known locations (work dir, HOME dir and CLASSPATH) for both
gemfire.properties and gfSecurity.properties, by default.
See here...
https://github.com/apache/geode/blob/rel/v1.2.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfigImpl.java#L864
Then here...
https://github.com/apache/geode/blob/rel/v1.2.0/geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java#L687
And finally, here...
https://github.com/apache/geode/blob/rel/v1.2.0/geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java#L690-L710
This...
https://github.com/apache/geode/blob/rel/v1.2.0/geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java#L691-L693
... is going to looking working directory (of the running GemFire
process... Locator/Server, Manager)
This...
https://github.com/apache/geode/blob/rel/v1.2.0/geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java#L700-L702
... checks the user's HOME dir, and finally...
This...
https://github.com/apache/geode/blob/rel/v1.2.0/geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java#L709
... resorts to resolving the [gemfire|gfSecurity].properties files from the
CLASSPATH.
I am not opposed to the `connect` command changing in how it deals with
SSL, but it should be...
1. Obvious to the user
2. Consistent where it is not obvious.
$0.02
-John
On Thu, Aug 3, 2017 at 2:24 PM, Jinmei Liao <ji...@pivotal.io> wrote:
> I don't have any problem of having all the "security" info in another
> properties file, but the fact that it's still trying to load a property
> file even if the command did not say so explicitly. I might have such a
> file sitting in my home dir for some occasions, but I may not want to use
> it in this command. If I do want it to load a gfSecurity.properties, I
> would have just issued "connect
> --security-properties-file=gfSecurity.properties" instead. This feature is
> there just to, in my opinion, save user a few key strokes in typing out the
> command, but it can cause a lot of unnecessary confusion and implementation
> hassle.
>
>
> On Thu, Aug 3, 2017 at 9:46 AM, Kirk Lund <kl...@apache.org> wrote:
>
> > Historically, gfSecurity.properties is a companion to gemfire.properties
> in
> > which sensitive key/value pairs can be kept in. The log banner does not
> (or
> > did not) log any values in gfSecurity.properties. Users would also
> > typically protect gfSecurity.properties with tighter permissions than
> > gemfire.properties.
> >
> > At the same time SecurityLogWriter was introduced to the APIs (Cache,
> > DistributedSystem). The idea behind this was that all security related
> log
> > statements would go to a special log file with tighter permissions.
> >
> > I would prefer not having either gfSecurity.properties or
> > SecurityLogWriter.
> > Now that we use Log4J2 for logging, it would be pretty straightforward to
> > configure "security" loggers to log to a special log file without having
> a
> > dedicated SecurityLogWriter. As for gfSecurity.properties, we already
> > redact all security related values from logging, so the only value of
> > having it is that Users who have permissions to read gemfire.properties
> can
> > be blocked from viewing the contents of gfSecurity.properties. I don't
> know
> > if this is useful or still a requirement for existing Users or not.
> >
> > I think another purpose for gfSecurity.properties was to avoid having
> > system properties such as -Dmy.password=foo from showing up in the list
> of
> > Java processes when using a command such as ps. There must be a better
> way
> > to protect against exposing sensitive configuration values.
> >
> > On Wed, Aug 2, 2017 at 10:15 PM, Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > I am looking at a behavior of Gfsh's connect command using ssl. I am
> not
> > > sure whether it's a valid use case or just some side effect of
> spaghetti
> > > code.
> > >
> > > So if SSL is configured on locator, and we need to connect to it in
> Gfsh
> > > gfsh>connect --security-properties-file=ssl.properties
> > > this will try to load the file for ssl configs, and use that for
> > > connection, sounds good.
> > >
> > > gfsh> connect --use-ssl
> > > this will look for a gfSecurity.properties file in current location,
> home
> > > dir, or classpath in order and use that for connection. But if that
> file
> > > doesn't exist or empty, it will prompt for all the ssl info.
> > >
> > > So when user issues "connect --use-ssl", sometimes they will get
> > prompted,
> > > sometimes not depending on whether this "special" file exists somewhere
> > in
> > > your environment. This just does not feel right. I am wondering if
> > looking
> > > for this "special" file really a good feature?
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>
--
-John
john.blum10101 (skype)
Re: behavior of "connect" command when --use-ssl
Posted by Jinmei Liao <ji...@pivotal.io>.
I don't have any problem of having all the "security" info in another
properties file, but the fact that it's still trying to load a property
file even if the command did not say so explicitly. I might have such a
file sitting in my home dir for some occasions, but I may not want to use
it in this command. If I do want it to load a gfSecurity.properties, I
would have just issued "connect
--security-properties-file=gfSecurity.properties" instead. This feature is
there just to, in my opinion, save user a few key strokes in typing out the
command, but it can cause a lot of unnecessary confusion and implementation
hassle.
On Thu, Aug 3, 2017 at 9:46 AM, Kirk Lund <kl...@apache.org> wrote:
> Historically, gfSecurity.properties is a companion to gemfire.properties in
> which sensitive key/value pairs can be kept in. The log banner does not (or
> did not) log any values in gfSecurity.properties. Users would also
> typically protect gfSecurity.properties with tighter permissions than
> gemfire.properties.
>
> At the same time SecurityLogWriter was introduced to the APIs (Cache,
> DistributedSystem). The idea behind this was that all security related log
> statements would go to a special log file with tighter permissions.
>
> I would prefer not having either gfSecurity.properties or
> SecurityLogWriter.
> Now that we use Log4J2 for logging, it would be pretty straightforward to
> configure "security" loggers to log to a special log file without having a
> dedicated SecurityLogWriter. As for gfSecurity.properties, we already
> redact all security related values from logging, so the only value of
> having it is that Users who have permissions to read gemfire.properties can
> be blocked from viewing the contents of gfSecurity.properties. I don't know
> if this is useful or still a requirement for existing Users or not.
>
> I think another purpose for gfSecurity.properties was to avoid having
> system properties such as -Dmy.password=foo from showing up in the list of
> Java processes when using a command such as ps. There must be a better way
> to protect against exposing sensitive configuration values.
>
> On Wed, Aug 2, 2017 at 10:15 PM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > I am looking at a behavior of Gfsh's connect command using ssl. I am not
> > sure whether it's a valid use case or just some side effect of spaghetti
> > code.
> >
> > So if SSL is configured on locator, and we need to connect to it in Gfsh
> > gfsh>connect --security-properties-file=ssl.properties
> > this will try to load the file for ssl configs, and use that for
> > connection, sounds good.
> >
> > gfsh> connect --use-ssl
> > this will look for a gfSecurity.properties file in current location, home
> > dir, or classpath in order and use that for connection. But if that file
> > doesn't exist or empty, it will prompt for all the ssl info.
> >
> > So when user issues "connect --use-ssl", sometimes they will get
> prompted,
> > sometimes not depending on whether this "special" file exists somewhere
> in
> > your environment. This just does not feel right. I am wondering if
> looking
> > for this "special" file really a good feature?
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
--
Cheers
Jinmei
Re: behavior of "connect" command when --use-ssl
Posted by Kirk Lund <kl...@apache.org>.
Historically, gfSecurity.properties is a companion to gemfire.properties in
which sensitive key/value pairs can be kept in. The log banner does not (or
did not) log any values in gfSecurity.properties. Users would also
typically protect gfSecurity.properties with tighter permissions than
gemfire.properties.
At the same time SecurityLogWriter was introduced to the APIs (Cache,
DistributedSystem). The idea behind this was that all security related log
statements would go to a special log file with tighter permissions.
I would prefer not having either gfSecurity.properties or SecurityLogWriter.
Now that we use Log4J2 for logging, it would be pretty straightforward to
configure "security" loggers to log to a special log file without having a
dedicated SecurityLogWriter. As for gfSecurity.properties, we already
redact all security related values from logging, so the only value of
having it is that Users who have permissions to read gemfire.properties can
be blocked from viewing the contents of gfSecurity.properties. I don't know
if this is useful or still a requirement for existing Users or not.
I think another purpose for gfSecurity.properties was to avoid having
system properties such as -Dmy.password=foo from showing up in the list of
Java processes when using a command such as ps. There must be a better way
to protect against exposing sensitive configuration values.
On Wed, Aug 2, 2017 at 10:15 PM, Jinmei Liao <ji...@pivotal.io> wrote:
> I am looking at a behavior of Gfsh's connect command using ssl. I am not
> sure whether it's a valid use case or just some side effect of spaghetti
> code.
>
> So if SSL is configured on locator, and we need to connect to it in Gfsh
> gfsh>connect --security-properties-file=ssl.properties
> this will try to load the file for ssl configs, and use that for
> connection, sounds good.
>
> gfsh> connect --use-ssl
> this will look for a gfSecurity.properties file in current location, home
> dir, or classpath in order and use that for connection. But if that file
> doesn't exist or empty, it will prompt for all the ssl info.
>
> So when user issues "connect --use-ssl", sometimes they will get prompted,
> sometimes not depending on whether this "special" file exists somewhere in
> your environment. This just does not feel right. I am wondering if looking
> for this "special" file really a good feature?
>
> --
> Cheers
>
> Jinmei
>