comodo的fd区分读写的最有可能被接受的方案。

urge

支持LZ

491866227

那就还不如建议comodo拦截读操作。默认在my protected files/folders里直接允许读操作。然后某个特定程序再进行限制读操作。像EQ那样不是更好？

distance0

如果真有这个选项了，需要慎重处理的是优先级问题，protected 和 blocked files 都阻止修改，删除，同时存在时候以哪个为准？不过现在考虑这个有点杞人忧天了。

distance0

原帖由 491866227 于 2008-11-19 21:57 发表
那就还不如建议comodo拦截读操作。默认在my protected files/folders里直接允许读操作。然后某个特定程序再进行限制读操作。像EQ那样不是更好？

现在的my protected files/folders就是允许读操作的，某个特定程序在哪里能再限制读操作？像eq那样，整个程序框架就要变，我估计再有用官方也不会去考虑的。

491866227

拦截的文件操作，本来就可以拦截读或写，哪来改变框架？

ps：呵呵，我又开始猜测了，当我没说过，楼主你继续，精神上支持你。

[ 本帖最后由 491866227 于 2008-11-19 22:06 编辑 ]

distance0

程序本身是能区分读和写的，不然怎么能读的允许，写的阻止？但是你怎么去控制，要有个选项，对于my protected files/folders里的文件，现在的框架能提供的选项就只有ask、allow、block，没有地方供你设置读写控制。

491866227

1，区分读和写只是一个或多个条件判断。
2，界面上的东西不能称之为框架。

distance0

问题是在哪里判断？界面反映的是程序的功能，程序功能就涉及到程序的框架。在security policy里面，各个项目的选项都是统一的，程序中应该有个部分统一管理。
况且在那里具体如果加判断呢？加上read allow、read ask、read block？那么你真想限制改写的规则该怎么办？comodo不允许给一个程序建2个以上规则，虽然可以变相实现。而且你要把所有文件都放在my protected files/folders里面，而blocked files却是空的。

491866227

你看到的allow ask block只是一个界面的一部分。
改变一下界面，不会改变程序架构。
好了，只能说到这了，再说下去已经没有共同语言。

distance0

大的架构不会变，小的部分就需要变了，改动越少，官方接受的可能性就越高，其实comodo很多地方都不尽如人意，灵活性很差，我们也许能构思出来一个完美的方案出来，但人家不接受什么都白搭。所以我说这个方案可能是最容易被接受的，因为本身已经有了blocked files了，在security policy里添加上也和其它选项保持一致，可以充分利用已有的条件。