Ilya, I don't think this is the best approach because there are so many properties that contain so many different types of information. "All or nothing" doesn't really fit here. We want to have the ability to exclude sensitive information, but still print out internal settings that are useful for debugging, etc.
-Val On Thu, Jul 1, 2021 at 9:54 AM Shishkov Ilya <shishkovi...@gmail.com> wrote: > Folks, > > > Maybe we should add an extra JVM option (e.g. > IGNITE_FORCE_PRINT_VM_ARGUMENTS) which is 'false' by default, > > but if set to 'true' then #ackVmOptions will print VM arguments even if > sensitive data is restricted? > > What do you think about an extra JVM option? > > чт, 1 июл. 2021 г. в 19:51, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > > Ivan, > > > > IP addresses (e.g. IGNITE_TCP_DISCOVERY_ADDRESSES) and file paths > > (e.g. IGNITE_CONFIG_URL) are often considered sensitive information. Data > > related to authentication (e.g. IGNITE_SSH_USER_NAME) is very likely to > be > > sensitive. > > > > Once again - I would exclude any property that can contain user-specific > > information. Only our internal settings (stuff > > like IGNITE_SQL_MERGE_TABLE_MAX_SIZE) are OK to appear in the logs. > > > > -Val > > > > On Thu, Jul 1, 2021 at 9:47 AM Ivan Daschinsky <ivanda...@gmail.com> > > wrote: > > > > > We can add add an extra param in annotation, that blocks param to be > > > printed, just set it to false by default and block it wheb set to true > > > > > > чт, 1 июл. 2021 г., 19:45 Atri Sharma <a...@apache.org>: > > > > > > > What if we allowed a blocklist of parameters that are never printed? > > > > > > > > On Thu, 1 Jul 2021, 22:06 Valentin Kulichenko, < > > > > valentin.kuliche...@gmail.com> wrote: > > > > > > > > > Not all of them are OK to be printed out. At the very least, we > > should > > > > have > > > > > a mechanism to exclude some of them. I would still go with opt-in > > > rather > > > > > than opt-out though, but I guess that is up to a discussion. > > > > > > > > > > -Val > > > > > > > > > > On Thu, Jul 1, 2021 at 9:29 AM Ivan Daschinsky < > ivanda...@gmail.com> > > > > > wrote: > > > > > > > > > > > This is security through obscurity, an obvious and a well-known > > anti > > > > > > pattern. I suppose that printing jvm options, that is registered > by > > > > > > @IgniteSystemProperty annotation is an ideal variant > > > > > > > > > > > > чт, 1 июл. 2021 г., 19:25 Valentin Kulichenko < > > > > > > valentin.kuliche...@gmail.com > > > > > > >: > > > > > > > > > > > > > Folks, > > > > > > > > > > > > > > *Anything* that a user provides to the system can potentially > be > > > > > > considered > > > > > > > sensitive information. This includes the VM arguments. We can't > > > > predict > > > > > > > what exactly one can put there, so let's not make assumptions. > > > > > > > > > > > > > > When dealing with security, we should be as conservative as > > > possible. > > > > > > That > > > > > > > said, I do not even agree with the pattern approach - there > might > > > be > > > > a > > > > > > > user's system property named IGNITE_xxx. It is also possible > for > > > our > > > > > > > internal properties to contain sensitive information (not all > of > > > them > > > > > are > > > > > > > boolean flags). > > > > > > > > > > > > > > The only option I see is to print out specific properties for > > which > > > > we > > > > > > > agree that they are safe. For example, we can introduce an > > > annotation > > > > > > that > > > > > > > would mark "safe" properties in IgniteSystemProperties; we will > > > then > > > > > > print > > > > > > > out only those that are marked with the annotation. > > > > > > > > > > > > > > -Val > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 1, 2021 at 7:07 AM Вячеслав Коптилин < > > > > > > slava.kopti...@gmail.com > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hello Ivan, > > > > > > > > > > > > > > > > > At least, we could just hide params that match a specific > > > pattern > > > > > > > > Yes, we can filter out all vm options that do not relate to > > > Ignite, > > > > > for > > > > > > > > instance. > > > > > > > > > > > > > > > > > Ilya, go ahead, file ticket and prepare a PR. > > > > > > > > Please do not rush. Let's listen to other community members. > > This > > > > > > > question > > > > > > > > is about security and it should not be discussed in a hurry > > (even > > > > > > though > > > > > > > it > > > > > > > > looks like an obvious thing). > > > > > > > > > > > > > > > > Thanks, > > > > > > > > S. > > > > > > > > > > > > > > > > чт, 1 июл. 2021 г. в 16:55, Ivan Daschinsky < > > ivanda...@gmail.com > > > >: > > > > > > > > > > > > > > > > > I suppose, that all normal users should not suffer from > this > > > > > > > > restrictions. > > > > > > > > > Nobody will pass password using jvm options. It is > absolutely > > > > > insane, > > > > > > > > > normal users pass passwords using environment variables. > > > > > > > > > > > > > > > > > > At least, we could just hide params that match specific > > pattern > > > > > > > > > > > > > > > > > > Ilya, go ahead, file ticket and prepare a PR. > > > > > > > > > > > > > > > > > > чт, 1 июл. 2021 г., 16:45 Вячеслав Коптилин < > > > > > > slava.kopti...@gmail.com > > > > > > > >: > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > Unfortunately, the user can pass its own system > properties > > > via > > > > > JVM > > > > > > > > > options > > > > > > > > > > as follows: -DMY_SECRET_PASSWORD=123 > > > > > > > > > > It does not seem, this approach is the best one. However, > > the > > > > > user > > > > > > > > should > > > > > > > > > > have a "kostyl" in order to hide these properties and > > values > > > in > > > > > the > > > > > > > log > > > > > > > > > > file, IMHO. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > S. > > > > > > > > > > > > > > > > > > > > ср, 30 июн. 2021 г. в 22:52, Shishkov Ilya < > > > > > shishkovi...@gmail.com > > > > > > >: > > > > > > > > > > > > > > > > > > > > > Hi Igniters, > > > > > > > > > > > > > > > > > > > > > > This feature [1, 2] prevents logging of the VM > arguments > > > when > > > > > > > > > > > IGNITE_TO_STRING_INCLUDE_SENSITIVE option is set to > > false. > > > > Till > > > > > > > now, > > > > > > > > > > method > > > > > > > > > > > IgniteKernal#ackVmArguments remains mostly the same > [3]. > > > > > > > > > > > > > > > > > > > > > > Is this behaviour actual now? Often, we should be able > to > > > get > > > > > > from > > > > > > > > logs > > > > > > > > > > the > > > > > > > > > > > actual VM options used at startup even if output of > > > sensitive > > > > > > data > > > > > > > is > > > > > > > > > > > restricted. > > > > > > > > > > > > > > > > > > > > > > 1. https://issues.apache.org/jira/browse/IGNITE-4991 > > > > > > > > > > > 2. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/ignite/pull/2428/commits/4f90b6fd77bd23fa818620f0757b792ba388ef93 > > > > > > > > > > > 3. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L3002 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
