你先确定一下反对意见的具体意思。
swap普通用户没有读权限。如果他担心密钥泄露给普通用户，那不会的。

如果是密钥写到磁盘就算泄露，那还挺麻烦的。
首先，应用程序的任何内存任何时候都可能被swap out，也就是说按照这个泄露的定义，密钥出现在内存里的瞬间就已经视作泄露了。你得提前mlock住会出现密钥的内存。
其次，hibernate to disk会把所有内存，包括mlock住的，写到磁盘。你的程序得有权限暂时阻止hibernate（root或通过policykit）。
ipc可以走/run/shm，当然也得mlock。
更简单的，如果可能的话，部署时关掉swap。
或者拼概率，密钥用完之后马上把其出现过的内存和文件清零。看“反对意见”是否接受了。

最好的方式，硬件狗一般有api让你在狗上完成“用第一个密钥加解密第二个密钥”这种操作，密钥不出狗。

【 在 bihai 的大作中提到: 】
: 最近开发一个小应用， 在Linux设备上要加密一个文件。我们是从硬件设备上获得一个秘钥来加密另一个秘钥。第二个秘钥是用来加密文件的。然后用第一个秘钥加密第二个秘钥，可以保存。
: 我的方案是第一个秘钥用原来的程序，稍作修改，把结果输出到文件，另写一个程序来进行加密，从文件中读取秘钥，从拎一个文件读取内容，加密结果输出到第三个文件。反馈说不行，怕文件被swap了，就是去保密了。
: 那我用pipe可以吧，stdout | stdin.
: ...................
--
修改:ilovecpp FROM 58.37.63.*
FROM 58.37.63.*

硬件本身的加密的内容太小，大约几兆，而我可能需要7-32兆，所以只能在内存中运行程序加密。

一般来说，一个程序内部生成秘钥，加密，然后加密秘钥，然后扔掉秘钥，就安全了。如果这个也能swap，那么这个人反对存到/tmp的理由就不成立了。我明天把这个说法告诉他，如果正在运行的程序swap了，和把秘钥存到/tmp里比有什么优势？

另一个人说我们这个设备就没有swap的分区，怎么swap。但是第一个人说，那以后改了呢？说实在的，其实不可能改，这个设备内存挺大，运行的程序又不多，我的程序是在系统刚启动就运行，哪有那么多机会swap.

【 在 ilovecpp 的大作中提到: 】
: 你先确定一下反对意见的具体意思。
: swap普通用户没有读权限。如果他担心密钥泄露给普通用户，那不会的。
: 如果是密钥写到磁盘就算泄露，那还挺麻烦的。
: ...................
--
FROM 98.42.143.*

启动时运行更简单了，你可以在swapon之前运行，或者临时swapoff。
不过就像楼上说的，狗的设计不是让你在用户机器上直接读密钥的，这个用法可能不对。

【 在 bihai 的大作中提到: 】
: 硬件本身的加密的内容太小，大约几兆，而我可能需要7-32兆，所以只能在内存中运行程序加密。
: 一般来说，一个程序内部生成秘钥，加密，然后加密秘钥，然后扔掉秘钥，就安全了。如果这个也能swap，那么这个人反对存到/tmp的理由就不成立了。我明天把这个说法告诉他，如果正在运行的程序swap了，和把秘钥存到/tmp里比有什么优势？
: 另一个人说我们这个设备就没有swap的分区，怎么swap。但是第一个人说，那以后改了呢？说实在的，其实不可能改，这个设备内存挺大，运行的程序又不多，我的程序是在系统刚启动就运行，哪有那么多机会swap.
: ...................
--
修改:ilovecpp FROM 58.37.63.*
FROM 58.37.63.*

named pipe和匿名pipe原理没有任何区别
你这个需求不要讨巧
【 在 bihai (new half life) 的大作中提到: 】
: 最近开发一个小应用， 在Linux设备上要加密一个文件。我们是从硬件设备上获得一个秘钥来加密另一个秘钥。第二个秘钥是用来加密文件的。然后用第一个秘钥加密第二个秘钥，可以保存。
: 我的方案是第一个秘钥用原来的程序，稍作修改，把结果输出到文件，另写一个程序来进行加密，从文件中读取秘钥，从拎一个文件读取内容，加密结果输出到第三个文件。反馈说不行，怕文件被swap了，就是去保密了。
: 那我用pipe可以吧，stdout | stdin.
: ...................
--
FROM 106.39.150.*