我有一个C程序，需要访问一个受保护的目录充满了东西。 强大的文本这个想法是只有程序或pipe理员才能访问。
在过去的Linux平台上， 我已经使用了文件系统SETUID和SETGID位。 程序运行得很好，因为无论是谁运行它，文件系统所说的UID和GID都是可执行文件的所有者。
或者说，它曾经运行成功。
我不知道到底是什么时候发生了这个变化，因为我只是倾向于在硬件故障时更新操作系统，所以我同时得到两个更新…所以，由于许多版本被跳过，我只有现在Fedora Core 17上的开发系统已经不再使用这些位了。 由于FC 19是目前的版本，我想象最新版本的情况只会更糟糕，而不是更好。
这是'ls -l'输出：
-rwsrwsr-x 1 cu cu 26403 Aug 28 2012 comp 在调查解决scheme时，我发现chmod的man页面说：
其他限制可能会导致MODE或RFILE的set-user-ID和set-group-ID位被忽略。 这种行为取决于底层chmod系统调用的策略和function。 如有疑问，请检查底层的系统行为。
好的，但我没有想法如何检查build议的政策和function！ 他们没有提供任何帮助，只是使用info命令 – 但是我没有find任何帮助，只有关于创build新文件的默认用户和组所有权的数据。
SELINUXclosures。
问题：
什么是现代这种事情的“正确”方式呢？
我如何检查政策 – 并改变它们？
感谢您的任何意见。
更多数据：
C程序只是有这条分支线来输出一个错误 – 一个摘录：
line=malloc(large); if (!line) printf("virtual memory exhausted\n"); if (line && FileExists(filename)) { if (access(filename,R_OK)==0) { cfile=fopen(filename, "r");
你的情况的问题是使用access() 。
man 2 access页面说：
The check is done using the calling process's real UID and GID, rather than the effective IDs as is done when actually attempting an operation (eg, open(2)) on the file. This allows set-user-ID programs to eas‐ ily determine the invoking user's authority.
当你用setuid二进制文件运行时，你只能改变你的有效的 UID而不是你真正的UID。 所以access()调用总是失败。
你应该删除access() 。 在这种情况下它是多余的，因为你使用fopen来打开文件，它也可以像这样进行访问检查，然后执行读取操作。