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