Skip to content
Advertisement

getuid/geteuid strange behaviour

I’ve got a simple code, which basically looks like:

package main

import (
    "fmt"
    "golang.org/x/sys/unix"
)

func main() {
    fmt.Printf("real: %d, effective: %dn", unix.Getuid(), unix.Geteuid())
}

Which basically outputs the real and effective user id. Now, once build with: go build main.go; I also call sudo chown root:root main && sudo chmod 4755 main to get -rwsr-xr-x permissions on the file.

If I understand the concept of the setuid bit (the s part), it allows me later to use setuid in the source file (noting, that I’ll have to use either unix.Setreuid or unix.RawSyscall in conjunction with runtime.LockOSThread). Yet, the current compiled code no matter what always returns real: 1000, effective: 1000.

At first I thought that maybe it is the case with some Go code, double and tripple checked it, yet, result is still the same. Then I went further and made a mock up in c:

int main(int argc, char* argv){
   printf("real: %d, effective: %dn", getuid(), geteuid());
   fflush(stdout);
}

Compiled, chown’ed to root:root, chmod’ed to 4755, and guess what? It still does the very same thing, it outputs real: 1000, effective: 1000.

So, if both: Go and C versions once compiled, properly changed in terms of permissions, return the same result: ignoring the setting, this is might to do something with system settings otherwise.

Update[0]: I’ve figured out that such a situation can be caused by a nosuid option for the mounted drive; so I’ve copied the executable to another drive, which doesn’t have such an option. Still no effect.

So, what should I do:

  1. To fight that behavior?
  2. To detect such an environment in future?

Looking forward to see your suggestions.

Advertisement

Answer

More deep research of the nosuid option showed that the whole process, including the compilation has to happen on the drive mounted without nosuid option.

So, basically speaking, the steps to fight the issue are:

  1. Create a directory on a nosuid disabled drive;
  2. Ensure directory group is your group;
  3. Ensure directory group permissions have w option;
  4. Copy the source to this directory;
  5. go build within the directory;
  6. Apply chown root:root to the result;
  7. Apply chmod 4755 to the result;
  8. Enjoy the result from /nonosuid/directory/

And to detect environment you need to search for a destination without nosuid parameter during the installation.

User contributions licensed under: CC BY-SA
3 People found this is helpful
Advertisement