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 >
