synoacltool的来时路，绿联的acl组怎么修（群晖现在怎么做的ACL）

强推Windows ACL 13种权限的事儿，群晖也干了（DSM5.0时期，2014年）

在DSM5.0之前，群晖也是标准的Linux POSIX权限，但是为了打入权限市场，解决Windows共享时复杂的权限继承问题，群晖在DSM5.0强行将所有共享文件夹切换为Windows ACL。当时外网直接炸锅了，因为很多用户发现，以前只需要在SSH里面敲chmod 777就能解决的问题在DSM5.0里执行之后，要么报错要么把整个文件夹的ACL都擦掉了（洗白，Strip）导致SMB文件服务出现错误甚至触发系统安全警报。
群晖官方支持Docker的初期的权限问题，DSM5.2~6.0时期
当群晖Docker开始支持时，就是今天绿联用户面对的问题，这个问题群晖老用户全经历过：1.容器跑起来了但是应用发现权限不对 2.用户root跑容器保证不会出现权限错误或者在GutHub上找第三方写的synoacltool Python封装脚本，通过crontask来强刷权限 3.老旧的NFSv3被用户当宝藏，因为它也可以把synoacl给直接洗掉
磨洋工把双轨制搞出来了（DSM6.2~7.x）
群晖在底层做了深度修改，主要原理是不再一刀切了，首先虽然群晖仍然在推Windows ACL，但是现在控制面板里面可以把共享文件夹退回POSIX ACL。其次群晖做了内核级别的映射，还魔改了ksmbd和samba服务的代码做了个vfs_synoacl以及在btrfs和ext4里面加了个扩展属性，现在群晖里面跑Docker时，如果容器请求检查0600权限时，群晖的内核会欺骗并动态翻译Windows ACL权限到POSIX ACL权限，Docker容器就会按预期工作了。

绿联现在的做法是在Debian系统上外挂了一个类似synoacltool的模块。SMB可以工作得很好，但是Linux这边完全就是懵的。因为没有映射，Docker容器会到处穿帮只能root执行来保证不出岔子

绿联的0777会牺牲安全性，群晖的0600可以把所有权锁死为owner自己。
群晖的核心技术是基于SMB VFS的动态映射。对内（docker等所有Linux服务）当你要求以0600读取一个文件时（发起open()调用），群晖的VFS会拦截并介入。它会实时查询用户的权限，然后向内核虚报一个权限掩码（Mask），对外就是映射成标准的Windows ACL权限。也就是说群晖的权限都是从VFS拿到的，而不是让程序读硬盘上的原始权限

绿联可以引入群晖双轨并行的VFS驱动，让VFS作为双向翻译官去翻译权限，运行在内核态（模仿群晖、威联通），然后把ugacltool从用户态配置升级到内核态策略，最后重构Docker的装载逻辑（整合用户身份），并提供退回到仅POSIX ACL功能