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

Question

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:

What is the "correct" way to do this kind of thing in the modern era?
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");

Is the program setuid correctly but not accessing that directory? What error do you get? Is it accessing a directory on disk or NFS? Is the program a script or a compiled application? — Matthew Ife, Oct 14 '13 at 00:08
@MIfe Sorry, I thought "program" was enough to make it clear it's NOT a script. It's actually a C program. I'm not sure just what the file access error would be, but it refuses the reads. Your guess about NFS was good: yes, NFS. ...The application was first written in 1997 or thereabouts and has worked all this time under the exact same scenario - the only thing that has changed is the OS version, even the build scripts and NFS mounting are the same! — Richard T, Oct 14 '13 at 00:24
Have you tested that your application works when you run it *as* the user its intended to run as to rule out another error? — Matthew Ife, Oct 14 '13 at 00:27
@MIfe Of course. It runs perfectly as the developer which is why I never noticed the problem over this long period of time! — Richard T, Oct 14 '13 at 00:28
@MIfe Note the code that's running is now in the question section above. At first I said maybe it was the part that was calling Java, but no, it has trouble before that and I cited the code... — Richard T, Oct 14 '13 at 00:37
I need more infomation, but this comment history will get quite full. You can join this chat; http://chat.stackexchange.com/rooms/11047/richard-t-and-mife — Matthew Ife, Oct 14 '13 at 00:38
let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/11048/discussion-between-richard-t-and-mife) — Richard T, Oct 14 '13 at 00:46
@MIfe I've been trying but there seems to be a bug; NOTHING happens. I either look at your link and it's blank, or I try the "automatically move this discussion to chat " and I see things but NO chance to type anything. It says I should log in to chat at the bottom BUT I AM LOGGED IN, clearly! — Richard T, Oct 14 '13 at 00:50

score 1 · Accepted Answer · answered Oct 14 '13 at 01:21

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.

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

1 Answers1