安全工具扫描问题 - 未受保护的写入 java
Security tool scan issue - Unguarded write in java
我有一个 java 格式如下的文件
class Demo {
private static Logger logger;
...
...
public static void main(){
// code to initialize logger
demoMethod()
}
private int demoMethod {
synchronized (tmpObj) {
...
helperMethod(tmpParam);
// some more logic of demoMethod related to file reading
logger.log("message from demo method");
...
//there is more logic that involves more loggers
}
}
private int helperMethod(int tmp){
//some logic of helperMethod related to Files
if(condition) {
logger.log("message from helperMethod");
}
return 1;
}
}
从上面的代码蓝图可以看出,我在 demoMethod(它有一个同步块)和 helpMethod 中都有记录器。现在我遇到的问题是
Unguarded read missing_lock: Accessing logger without holding lock TempClassName.tmpObj Elsewhere, logger is accessed with TempClassName.tmpObj held 8 out of 12 times.
我不太确定是什么导致了这个问题,因为我使用的记录器是线程安全的。谁能就可能导致此问题的原因提供更多见解。
此报告的主要原因是:“在其他地方,12 次中有 8 次 TempClassName.tmpObject 访问记录器。”也就是说,成员 logger
在源代码中的 12 个文本位置被访问(读取或写入,但不包括初始化),并且对于其中的 8 个位置,已知 tmpObject
锁被持有执行线程。因此,该工具得出结论,程序员的意图是 tmpObject
必须 才能访问 logger
。显然,12 个中有 8 个高于将关联视为巧合的可配置阈值。因此,该工具将与模式的偏差报告为可能的错误。我天真地期望 logger
总共有 4 份报告,其中你引用的是一份(尽管它可能因存在不同的可能调用路径而变得复杂)。
这可能是误报。这个检查器对同步问题没有深刻的理解,它只是从它在代码中发现的模式进行推断。如果,如您所说,Logger
class 是线程安全的,那么 和 就没有 read/write 或 write/write 危险logger
会员本身,那么可以安全地将此报告视为虚假。
此外,请注意,在您提供的代码片段中,helperMethod
是 private
,仅调用一次,并且该调用站点本身位于 synchronized
块中。如果真实代码没有任何其他调用站点,那么这可能只是 Coverity 工具中的一个错误,因为 helperMethod
中的访问总是在持有锁时发生,并且该工具应该意识到这一点事实上
但还有一个问题:您引用的消息指的是 tmpObject
,而您 post 编辑的代码指的是 tmpObj
,它们是不同的名称。这只是您 post 中的错字,还是真正的代码实际上有两个不同的“临时对象” 运行 造成混淆?如果是这样,那可能才是真正的问题。
撇开这份报告的细节不谈,请注意 Java 并发性比乍看起来要困难和微妙得多。如果您不精通该主题(对于初学者,您是否对“之前发生过”有扎实的了解?),请在驳回报告之前咨询或做一些额外的研究。这个检查器的理解可能很肤浅,但根据我的经验,仔细检查它标记的任何代码中并发的使用通常是值得的。
披露:我之前受雇于 Synopsys/Coverity 并帮助构建了 Coverity 工具。
我有一个 java 格式如下的文件
class Demo {
private static Logger logger;
...
...
public static void main(){
// code to initialize logger
demoMethod()
}
private int demoMethod {
synchronized (tmpObj) {
...
helperMethod(tmpParam);
// some more logic of demoMethod related to file reading
logger.log("message from demo method");
...
//there is more logic that involves more loggers
}
}
private int helperMethod(int tmp){
//some logic of helperMethod related to Files
if(condition) {
logger.log("message from helperMethod");
}
return 1;
}
}
从上面的代码蓝图可以看出,我在 demoMethod(它有一个同步块)和 helpMethod 中都有记录器。现在我遇到的问题是
Unguarded read missing_lock: Accessing logger without holding lock TempClassName.tmpObj Elsewhere, logger is accessed with TempClassName.tmpObj held 8 out of 12 times.
我不太确定是什么导致了这个问题,因为我使用的记录器是线程安全的。谁能就可能导致此问题的原因提供更多见解。
此报告的主要原因是:“在其他地方,12 次中有 8 次 TempClassName.tmpObject 访问记录器。”也就是说,成员 logger
在源代码中的 12 个文本位置被访问(读取或写入,但不包括初始化),并且对于其中的 8 个位置,已知 tmpObject
锁被持有执行线程。因此,该工具得出结论,程序员的意图是 tmpObject
必须 才能访问 logger
。显然,12 个中有 8 个高于将关联视为巧合的可配置阈值。因此,该工具将与模式的偏差报告为可能的错误。我天真地期望 logger
总共有 4 份报告,其中你引用的是一份(尽管它可能因存在不同的可能调用路径而变得复杂)。
这可能是误报。这个检查器对同步问题没有深刻的理解,它只是从它在代码中发现的模式进行推断。如果,如您所说,Logger
class 是线程安全的,那么 和 就没有 read/write 或 write/write 危险logger
会员本身,那么可以安全地将此报告视为虚假。
此外,请注意,在您提供的代码片段中,helperMethod
是 private
,仅调用一次,并且该调用站点本身位于 synchronized
块中。如果真实代码没有任何其他调用站点,那么这可能只是 Coverity 工具中的一个错误,因为 helperMethod
中的访问总是在持有锁时发生,并且该工具应该意识到这一点事实上
但还有一个问题:您引用的消息指的是 tmpObject
,而您 post 编辑的代码指的是 tmpObj
,它们是不同的名称。这只是您 post 中的错字,还是真正的代码实际上有两个不同的“临时对象” 运行 造成混淆?如果是这样,那可能才是真正的问题。
撇开这份报告的细节不谈,请注意 Java 并发性比乍看起来要困难和微妙得多。如果您不精通该主题(对于初学者,您是否对“之前发生过”有扎实的了解?),请在驳回报告之前咨询或做一些额外的研究。这个检查器的理解可能很肤浅,但根据我的经验,仔细检查它标记的任何代码中并发的使用通常是值得的。
披露:我之前受雇于 Synopsys/Coverity 并帮助构建了 Coverity 工具。