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
