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 <jil...@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 <jil...@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)
