ftok()碰撞 [英] ftok() collisions

问题描述

我正在使用ftok()为C应用程序使用的共享内存段生成标识符.我遇到了问题，在一个盒子上，我与root使用的标识符发生冲突.在这种情况下，我可以通过修改代码来修复它，但是我想要一个更强大的解决方案.

I am using ftok() to generate identifiers for shared memory segments used by a C application. I am having problems, where on one box I am getting collisions with the identifiers used by root. I can fix it in this instance by hacking the code, but I would like a more robust solution.

该应用程序已安装到其自己的逻辑卷中，提供给ftok的路径是该应用程序的二进制目录(在该lv内).提供的ID从1开始，通常大约是六个.

The application is installed into its own logical volume, and the path supplied to ftok is the binaries directory for the application (within that lv). The IDs supplied start at 1 and there are usually half a dozen or so.

我已经发现ftok会执行以下操作:

I've tracked down that ftok will do something like this:

(id & 0xff) << 24 | (st.st_dev & 0xff) << 16 | (st.st_ino & 0xffff)

st.st_dev/st.st_ino的组合应该非常独特.但是我看到了很多方框，st_dev的最低有效位通常是0(即st_dev的数字通常是256的倍数).而且由于二进制目录位于逻辑卷中，因此不能保证inode编号与root使用的编号有所不同.

The combination of st.st_dev / st.st_ino should be very unique. But I've seen across a number of boxes, the least significant bit of st_dev is often 0 (i.e. st_dev numbers are generally multiples of 256). And because the binary directory is in a logical volume, there is no guarantee that the inode number will be different from something root uses.

是否有解决此问题的好方法-替代ftok的更好方法，还是设置机器以使st_dev编号更适合ftok的方法?

Is there a good way around this - a better alternative to ftok, or a way of setting up machines such that the st_dev numbers will be of more use to ftok?

推荐答案

您可能要考虑使用POSIX共享内存(通过

You may want to consider using POSIX shared memory (via shm_open), which doesn't suffer from this sort of key collision

这篇关于ftok()碰撞的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！