想了解一下诸位的跨进程通讯方案

[yaott2020]

自己写一个项目，某些情境下需要管理员权限执行命令，频繁弹出 UAC 很影响用户体验。所以将这部分功能分离，做成服务，主程序与其进行通信。由于项目特殊性，主程序与服务通讯时尽可能绕过网络栈。因为之前没有遇到需要跨进程通讯的情景，自己 Google 并找到以下解决方案：

- 在 Windows 下采用 NamePipe
- 在 Unix 下采用 UnixDomainSocket

为保证安全性，还在其中包装了 TLS ，双向证书验证，即 NamePipe+TLS / UnixDomainSocket+TLS 。

想请教一下诸位的方案，并欢迎提出上述方案的修改建议

[tool2dx]

我是直接把临时数据，写在注册表做进程共享的。不需要特殊权限，简单，暴力。

[tool2dx]

还有就是 WM_COPYDATA ，也不需要权限，挺方便。

[james122333]

你这样很难调试 出了问题也难以修正 组件互动也过于单一化

[james122333]

当然做别人的东西应该都会差不多这么搞 多人懂 东西不好不坏

[GeekGao]

命名管道最简单， 安全方案都是 ms 标准的东西 https://learn.microsoft.com/en-us/windows/win32/ipc/named-pipe-security-and-access-rights

[yaott2020]

@james122333 个人项目，而且用过一些现成的库，都不好用，这段代码是参考字节的相关代码写的，应该不会有什么大的问题

[yaott2020]

@GeekGao Windows 下用的就是 NamedPipe

[yaott2020]

@tool2dx 主要需要读取一些流数据，频繁读写注册表不会有什么性能问题吧

[zhangeric]

windows 可以使用共享内存.

[bthulu]

当然是 GRPC 配合 OAUTH 了

[specture]

在端上应该 NamedPipe 和 UDS 是比较好的方案了.

[salmon5]

为保证安全性，还在其中包装了 TLS ，双向证书验证，即 NamePipe+TLS / UnixDomainSocket+TLS 。
================================================================
这个感觉没必要。

[codehz]

不是你进程内用 TLS 是脱裤子放屁吗，威胁模型先确定一下啊，桌面系统可能存在的问题是病毒劫持了你的程序伪造发送消息，你这个用 TLS 有啥意义，只要病毒能注入代码到低权限进程，就可以轻易伪造，有没有 TLS 都没区别。。。
同一个机器上的话应该由特权进程来验证通讯的进程是否合法...windows 使用 com 的远程调用机制是可以做到的，可以参考 Chrome 最近在 windows 上使用的一个叫做“App-Bound”的机制（保护 cookie 不被其他进程解密的）

[yaott2020]

@salmon5 服务可以以管理员执行任意命令，需要鉴权和保证安全性

[yaott2020]

@codehz 是两个进程

[yaott2020]

@codehz 感谢分享，我再了解