storm源码分析(三)


2021SC@SDUSC

AclEnforcement类,这是用于执行ZK acl的类。
我们首先介绍一些关于ACLs权限的知识。

一、ACLs权限

权限

1) CREATE: 创建权限,可以在在当前node下创建child node
2) DELETE(d): 删除权限,可以删除当前的node
3) READ: 读权限,可以获取当前node的数据,可以list当前node所有的child nodes
4) WRITE(w): 写权限,可以向当前node写数据
5) ADMIN(a): 管理权限,可以设置当前node的permission

维度

从三个维度来理解:一是scheme; 二是user(可以用户名或者ip); 三是permission(即上面的权限),通常表示为scheme?permissions。

1.scheme

scheme: scheme对应于采用哪种方案来进行权限管理,zookeeper实现了一个pluggable的ACL方案,可以通过扩展scheme,来扩展ACL的机制。zookeeper-3.4.4缺省支持下面几种scheme:

world:
它下面只有一个id, 叫anyone, world:anyone代表任何人,zookeeper中对所有人有权限的结点就是属于world:anyone的

auth:
它不需要id, 只要是通过authentication的user都有权限(zookeeper支持通过kerberos来进行authencation, 也支持username/password形式的authentication)

digest:
它对应的id为username:BASE64(SHA1(password)),它需要先通过username:password形式的authentication

ip:
它对应的id为客户机的IP地址,设置的时候可以设置一个ip段,比如ip:192.168.1.0/16, 表示匹配前16个bit的IP段

super:
在这种scheme情况下,对应的id拥有超级权限,可以做任何事情(cdrwa)

sasl:
sasl的对应的id,是一个通过sasl authentication用户的id,zookeeper-3.4.4中的sasl authentication是通过kerberos来实现的,也就是说用户只有通过了kerberos认证,才能访问它有权限的node。

2.id

id与scheme是紧密相关的,具体的情况在上面介绍scheme的过程都已介绍,这里不再赘述。

3.permission

权限cdrwa。

二、代码分析

verifyAcls()方法

该方法主要是验证ZK acl是否正确,并在需要时可选地修复它们。
该方法传入的变量conf为集群配置,如果要修复acl则传入的fixUp为true,否的话为false。

public static void verifyAcls(Map<String, Object> conf, final boolean fixUp) throws Exception {
        if (!Utils.isZkAuthenticationConfiguredStormServer(conf)) {
            LOG.info("SECURITY IS DISABLED NO FURTHER CHECKS...");
            //There is no security so we are done.
            return;
        }
        ACL superUserAcl = Utils.getSuperUserAcl(conf);
        List<ACL> superAcl = new ArrayList<>(1);
        superAcl.add(superUserAcl);

        List<ACL> drpcFullAcl = new ArrayList<>(2);
        drpcFullAcl.add(superUserAcl);

        String drpcAclString = (String) conf.get(Config.STORM_ZOOKEEPER_DRPC_ACL);
        if (drpcAclString != null) {
            Id drpcAclId = Utils.parseZkId(drpcAclString, Config.STORM_ZOOKEEPER_DRPC_ACL);
            ACL drpcUserAcl = new ACL(ZooDefs.Perms.READ, drpcAclId);
            drpcFullAcl.add(drpcUserAcl);
        }

首先先通过Utils.isZkAuthenticationConfiguredStormServer()方法判断Storm服务器是否配置了Zk认证。否的话我们认为是不安全的直接返回。
如果配置了,则获取superUser的Acl权限,加入到superAcl和drpcFullAcl的权限列表中。

 List<String> zkServers = (List<String>) conf.get(Config.STORM_ZOOKEEPER_SERVERS);
        int port = ObjectReader.getInt(conf.get(Config.STORM_ZOOKEEPER_PORT));
        String stormRoot = (String) conf.get(Config.STORM_ZOOKEEPER_ROOT);

        try (CuratorFramework zk = ClientZookeeper.mkClient(conf, zkServers, port, "",
                                                            new DefaultWatcherCallBack(), conf, DaemonType.NIMBUS)) {
            if (zk.checkExists().forPath(stormRoot) != null) {
                //First off we want to verify that ROOT is good
                verifyAclStrict(zk, superAcl, stormRoot, fixUp);
            } else {
                LOG.warn("{} does not exist no need to check any more...", stormRoot);
                return;
            }
        }


经过上面的处理现在根路径已经没问题了,下面开始查看它下面的其他路径。

try (CuratorFramework zk = ClientZookeeper.mkClient(conf, zkServers, port, stormRoot,
                                                            new DefaultWatcherCallBack(), conf, DaemonType.NIMBUS)) {
            //Next verify that the blob store is correct before we start it up.
            if (zk.checkExists().forPath(ClusterUtils.BLOBSTORE_SUBTREE) != null) {
                verifyAclStrictRecursive(zk, superAcl, ClusterUtils.BLOBSTORE_SUBTREE, fixUp);
            }

            if (zk.checkExists().forPath(ClusterUtils.BLOBSTORE_MAX_KEY_SEQUENCE_NUMBER_SUBTREE) != null) {
                verifyAclStrict(zk, superAcl, ClusterUtils.BLOBSTORE_MAX_KEY_SEQUENCE_NUMBER_SUBTREE, fixUp);
            }

            //The blobstore is good, now lets get the list of all topo Ids
            Set<String> topoIds = new HashSet<>();
            if (zk.checkExists().forPath(ClusterUtils.STORMS_SUBTREE) != null) {
                topoIds.addAll(zk.getChildren().forPath(ClusterUtils.STORMS_SUBTREE));
            }

            Map<String, Id> topoToZkCreds = new HashMap<>();
            //Now lets get the creds for the topos so we can verify those as well.
            BlobStore bs = ServerUtils.getNimbusBlobStore(conf, NimbusInfo.fromConf(conf), null);
            try {
                Subject nimbusSubject = new Subject();
                nimbusSubject.getPrincipals().add(new NimbusPrincipal());
                for (String topoId : topoIds) {
                    try {
                        String blobKey = topoId + "-stormconf.ser";
                        Map<String, Object> topoConf = Utils.fromCompressedJsonConf(bs.readBlob(blobKey, nimbusSubject));
                        String payload = (String) topoConf.get(Config.STORM_ZOOKEEPER_TOPOLOGY_AUTH_PAYLOAD);
                        try {
                            topoToZkCreds.put(topoId, new Id("digest", DigestAuthenticationProvider.generateDigest(payload)));
                        } catch (NoSuchAlgorithmException e) {
                            throw new RuntimeException(e);
                        }
                    } catch (KeyNotFoundException knf) {
                        LOG.debug("topo removed {}", topoId, knf);
                    }
                }
            } finally {
                if (bs != null) {
                    bs.shutdown();
                }
            }

接下来,在启动blob存储之前,先验证blob存储是否正确。
blobstore存储正确的话,就获取所有topo id的列表,然后得到topos的creds,这样也可以验证其他的。

verifyParentWithReadOnlyTopoChildren(zk, superUserAcl, ClusterUtils.STORMS_SUBTREE, topoToZkCreds, fixUp);
            verifyParentWithReadOnlyTopoChildren(zk, superUserAcl, ClusterUtils.ASSIGNMENTS_SUBTREE, topoToZkCreds, fixUp);
            //There is a race on credentials where they can be leaked in some versions of storm.
            verifyParentWithReadOnlyTopoChildrenDeleteDead(zk, superUserAcl, ClusterUtils.CREDENTIALS_SUBTREE, topoToZkCreds, fixUp);
            //There is a race on logconfig where they can be leaked in some versions of storm.
            verifyParentWithReadOnlyTopoChildrenDeleteDead(zk, superUserAcl, ClusterUtils.LOGCONFIG_SUBTREE, topoToZkCreds, fixUp);
            //There is a race on backpressure too...
            verifyParentWithReadWriteTopoChildrenDeleteDead(zk, superUserAcl, ClusterUtils.BACKPRESSURE_SUBTREE, topoToZkCreds, fixUp);

            if (zk.checkExists().forPath(ClusterUtils.ERRORS_SUBTREE) != null) {
                //errors is a bit special because in older versions of storm the worker created the parent directories lazily
                // because of this it means we need to auto create at least the topo-id directory for all running topos.
                for (String topoId : topoToZkCreds.keySet()) {
                    String path = ClusterUtils.errorStormRoot(topoId);
                    if (zk.checkExists().forPath(path) == null) {
                        LOG.warn("Creating missing errors location {}", path);
                        zk.create().withACL(getTopoReadWrite(path, topoId, topoToZkCreds, superUserAcl, fixUp)).forPath(path);
                    }
                }
            }
            //Error should not be leaked according to the code, but they are not important enough to fail the build if
            // for some odd reason they are leaked.
            verifyParentWithReadWriteTopoChildrenDeleteDead(zk, superUserAcl, ClusterUtils.ERRORS_SUBTREE, topoToZkCreds, fixUp);

            if (zk.checkExists().forPath(ClusterUtils.SECRET_KEYS_SUBTREE) != null) {
                verifyAclStrict(zk, superAcl, ClusterUtils.SECRET_KEYS_SUBTREE, fixUp);
                verifyAclStrictRecursive(zk, superAcl, ClusterUtils.secretKeysPath(WorkerTokenServiceType.NIMBUS), fixUp);
                verifyAclStrictRecursive(zk, drpcFullAcl, ClusterUtils.secretKeysPath(WorkerTokenServiceType.DRPC), fixUp);
            }

            if (zk.checkExists().forPath(ClusterUtils.NIMBUSES_SUBTREE) != null) {
                verifyAclStrictRecursive(zk, superAcl, ClusterUtils.NIMBUSES_SUBTREE, fixUp);
            }

            if (zk.checkExists().forPath("/leader-lock") != null) {
                verifyAclStrictRecursive(zk, superAcl, "/leader-lock", fixUp);
            }

            if (zk.checkExists().forPath(ClusterUtils.PROFILERCONFIG_SUBTREE) != null) {
                verifyAclStrictRecursive(zk, superAcl, ClusterUtils.PROFILERCONFIG_SUBTREE, fixUp);
            }

            if (zk.checkExists().forPath(ClusterUtils.SUPERVISORS_SUBTREE) != null) {
                verifyAclStrictRecursive(zk, superAcl, ClusterUtils.SUPERVISORS_SUBTREE, fixUp);
            }

            // When moving to pacemaker workerbeats can be leaked too...
            verifyParentWithReadWriteTopoChildrenDeleteDead(zk, superUserAcl, ClusterUtils.WORKERBEATS_SUBTREE, topoToZkCreds, fixUp);
        }
    }

验证带有只读拓扑子结点的父结点。
在某些版本的storm中,有关于证书的竞争,有在logconfig上的竞争,还有在backpressure反压力上的竞争。所以要将已经死了的带有只读拓扑子结点的父结点删除。
如果zk.checkExists().forPath(ClusterUtils.ERRORS_SUBTREE) 非空,也就是存在ClusterUtils.ERRORS_SUBTREE的路径,就需要为所有运行的topos自动创建至少一个topo-id目录。因为Errors有一点特殊,因为在旧版本的storm中,工人创建父目录是惰性的。
然后对ClusterUtils.SECRET_KEYS_SUBTREE,ClusterUtils.NIMBUSES_SUBTREE,"/leader-lock",ClusterUtils.PROFILERCONFIG_SUBTREE,ClusterUtils.SUPERVISORS_SUBTREE路径非空的节点做相应的处理验证递归。
当移动到pacemaker时,心跳也会被泄露,这是就删除这些死了的带有只读拓扑子结点的父结点。

getTopoAcl()方法

private static List<ACL> getTopoAcl(String path, String topoId, Map<String, Id> topoToZkCreds, ACL superAcl, boolean fixUp, int perms) {
        Id id = topoToZkCreds.get(topoId);
        if (id == null) {
            String error = "Could not find credentials for topology " + topoId + " at path " + path + ".";
            if (fixUp) {
                error += " Don't know how to fix this automatically. Please add needed ACLs, or delete the path.";
            }
            throw new IllegalStateException(error);
        }
        List<ACL> ret = new ArrayList<>(2);
        ret.add(superAcl);
        ret.add(new ACL(perms, id));
        return ret;
    }

该方法先通过拓扑的id来得到权限,加入到权限列表中,最后返回权限列表。

参考链接:https://blog.csdn.net/linwu_2006_2006/article/details/95062838

前言:其实一年前研究mpq加密的时候就有这个想法,后来对加密失去兴趣,没有应用而已。 先从mpq读取(和写入)说起。市面上的软件大致有以下几种方法: 0.listfile式。0这个数字说明了它的原始。如果mpq没有用listfile明确叙述自己的文件组成,它就无法读取其中的文件。怎么说呢,这就好像只要犯人不招认,自己也认为犯人无罪的笨蛋侦探一样,严谨到无聊。典型例子不是别人,正是大名鼎鼎的WorldEditor地图编辑器。对付这种软件,删掉listfile就一切安好。 1.小白式。这种软件基本上用自制的dll(因为暴雪只提供了读mpq的storm.dll,没有写入),按照mpq文件格式非常循规蹈矩地一步步读出内容。问题在于mpq数据稍有不对就会导致崩溃。例如header中mpq文件大小这项数据,war3读地图的时候根本不管,所以怎么写都不影响地图工作,但这类工具却会照着此数据读图,然后掉进番茄海的无底深渊。 典型例子是winmpq和mpqmaster。 2.storm式。以火龙hke为代表。这类mpq软件用暴雪提供的storm.dll读取mpq,读取方式和暴雪一致。由于mpq文件被设计成“知道文件名(含路径)可以很容易读取,但扫描所有文件路径却几乎不可能”的格式,war3在读地图时只用在需要的时候读指定文件就ok,所以这类编辑器也模拟war3读地图的方式,逐渐推算出“需要的文件”从而读出地图中近乎全部文件,只要在物编中涉及到或jass中提及的路径,都会检测对应的文件并列在表中。这是一种近乎无敌的方法,不会报错(否则war3也玩不了这图),且war3map.j等固定文件必然被扫描出来(否则war3自己也找不到)。 然后是重点: 但这里有个致命问题——不管是火龙还是war3,不可能预知到游戏过程中全部的文件读取,更确切说,全部的字符串。如果字符串是明文写在脚本中,如“sound\\aaa.mp3”,那么火龙会认为这可能是个文件,然后顺藤摸瓜找到它。但如果写成“sound\\” + “aaa.mp” + I2S(3)等甚至加上存取哈希表动作,火龙或任何软件也无法完全预知。这种不可预测是理论级的,即“图灵机无法预测另一台图灵机的全部可能状态”,等价于著名的“停机问题”,而停机问题是“理论不可计算”的。所以在游戏中虽然能正常听到音乐(或看到特效等),但火龙却无法提前知道这个文件的存在。 样例的图中正是这样,隐藏了一个2m+的mp3文件,但火龙却只能读出一大打war3map.xxx。 然后这种方法也能隐藏其它文件,但无法隐藏在物编中使用到的文件(如被某单位使用的导入模型)、地图必备文件(如j)和覆盖原路径文件(如替换的载入图片)。 3.hash扫描式。但是还没完,还有一种方式,某些软件绕过mpq前面的哈希索引表,直接扫描后面的文件,这样虽然不能知道文件名,但能得到完整的文件列表(再怎么说文件也是封在mpq里的吧,把mpq整个扫一遍总能发现)。例子是新版mpqeditor,样例图和某人提供的火影图都能打开,能看到一堆没有文件名的文件,其中就有隐藏的mp3,改成mp3扩展名就能正常播放。这种方式应该没什么弊端(除了得不到正确文件名),如果和火龙结合,用上述方法隐藏的文件也能以“未知名文件”的形式显示出来,其他文件则完美显示。 所以mpq这种文件格式终究逃不过被拆的厄运,想完美隐藏文件果然是不可能的事情。全文完。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值