Home / server / Questions / 545738
Accepted
Richard T
Asked: 2013-10-14 16:00:19 +0800 CST

SETUID / SETGID on a binary executable stopped working following upgrade of Fedora Core

  • 772

I have a C program that needs access to a protected directory full of stuff.strong text The idea is that only the program or the administrator have access.

In the past on Linux platforms, I've used the file-system SETUID and SETGID bits rather successfully. The program runs just fine as whatever the UID and GID the file system says is the owner of the executable no matter who runs it.

Or, rather, it used to run successfully.

I don't know exactly when this change occurred because I only tend to update the OS when there's a hardware failure, so I get both updates at once... So, given lots of versions are skipped, I, only that as of right now, the development system that's on Fedora Core 17 is no longer honoring these bits. As FC 19 is the current release, I imagine things are only worse with the latest release, not better.

Here's the 'ls -l' output:

-rwsrwsr-x 1 cu cu 26403 Aug 28  2012 comp

In investigating a solution, I found the man page for chmod says this:

Additional restrictions may cause the set-user-ID and set-group-ID bits of MODE or RFILE to be ignored. This behavior depends on the policy and functionality of the underlying chmod system call. When in doubt, check the underlying system behavior.

OK, but I have NO IDEA how to check that policy and functionality as suggested! They offered no help but to use the info command - but I found nothing helpful there, only data about default user and group ownership for new file creation.

SELINUX is turned off.

Questions:

  1. What is the "correct" way to do this kind of thing in the modern era?

  2. How do I check the policies - and alter them?

Thanks for any input.

MORE DATA:

The C program simply has this line that's branching to output an error - an excerpt:

  line=malloc(large);
  if (!line) printf("virtual memory exhausted\n");
  if (line && FileExists(filename))
  {
     if (access(filename,R_OK)==0)
     {
        cfile=fopen(filename, "r");
setuid

1 Answers

  1. Best Answer

    The problem in your case is the use of access().

    The man 2 access page says:

      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
  (e.g., open(2)) on the file.  This allows set-user-ID programs to  eas‐
  ily determine the invoking user's authority.

    When you run with setuid binaries you only change your effective UID not your real one. So the access() call will always fail.

    You should remove the access(). Its redundant in this case since you use fopen to open the file anyway, its also racey to perform an access check like that and then perform a read on it.

    • 1