seteuid apps report perror() on trying /proc/self/auxv

[Walter]

Hi,

my uwsgi log started spamming unknown errors, looking like this:

  Error opening file for reading: Permission denied

After a bit of investigation, it turned out that libjpeg-turbo was the culprit -- and specifically, the ubuntu-specific edits found in FixLibraryStartup.patch:

+ auxv_f = fopen("/proc/self/auxv", "r");
+
+ if(auxv_f == 0) {
+ perror("Error opening file for reading");
+ return 0;
+ }

What happens is this:

  uwsgi drops its privileges and exec's to an unprivileged child. The /proc/self/auxv is still owned by root, and then we get the error.

See this example (source files below):

== Example ==

$ sudo ./normal
./normal: 0

$ sudo ./droppriv
./droppriv: 0
Error opening file for reading: Permission denied
./normal: 0

=====

I don't mind that I don't get NEON optimizations (I don't, because I'm not on an ARM), but I do mind hard to track down errors that aren't affecting me.

Can we tone down the seriousness by removing the perror()?

Kind regards,
Walter Doekes
OSSO B.V.

== normal.c ==

#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

#include <stdio.h>
#include <jpeglib.h>

int main(int argc, char const *const *argv) {
 struct stat st;
 struct jpeg_compress_struct cinfo = { 0, };
 stat("/proc/self/auxv", &st);
 printf("%s: %d\n", argv[0], st.st_uid);
 jpeg_create_compress(&cinfo);
 return 0;
}

== droppriv.c ==

#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

#include <stdio.h>

int main(int argc, char const *const *argv) {
 struct stat st;
 seteuid(1000);
 stat("/proc/self/auxv", &st);
 printf("%s: %d\n", argv[0], st.st_uid);
 execl("./normal", "./normal", NULL);
}

== Makefile ==

.PHONY: all clean
all: droppriv normal
droppriv: droppriv.c
 $(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
normal: normal.c
 $(CC) $(CFLAGS) $(LDFLAGS) $< -ljpeg -o $@
clean:
 $(RM) droppriv normal

[Roland Hughes (original-seasoned-geek)]

dropping perror() is not going to fix this by itself. I have a QT application. Thank you dearly for your explanation found here:

http://lukasz.langa.pl/5/error-opening-file-for-reading-permission-denied/

I tried to work around this as follows:

    // Code to get around a bogus Ubuntu protection problem with the
    // sticky "s" permision on executable file.
    //
    QDir d("/proc/self");
    QFileInfoList dLst = d.entryInfoList();
    int cx;

    foreach( const QFileInfo flInfo, dLst)
    {
        if (flInfo.isFile())
        {
            FILE_LOG(logINFO) << "changing ownership of " << qPrintable(flInfo.absoluteFilePath());
            cx = chown(qPrintable(flInfo.absoluteFilePath()), ruid, ruid);
        }
    }
    errno = 0; // don't let stale errors impact us later

    if (seteuid(ruid) != 0)
    {
        FILE_LOG(logINFO) << "seteuid failed errno " << errno;
    }

STILL no love.

What is interesting is that I run at root yet cannot change owner on the directories.

I think a more accurate fix would be for the sticky bit processes to create all /proc/self entries with owners of "user:root" but don't have a method of testing this.

WE REALLY NEED A FIX. Under the compiler shipped with Mint 14 (and probably included with 12.10) this "benign" error is now fatal.

[Martin von Gagern (gagern)]

Since this is a problem with an Ubuntu patch, I'd not consider this a bug against the libjpeg-turbo package, as it is currently filed. And for Ubuntu, there already is bug #1031718 to track this beast here. Although seeing how long this has remained unfixed makes me doubt we'll see any change any time soon.

By the way, I'm seeing this with an apache process that has inherited cap_net_bind_service flag. For reasons unknown, I'm seeing this during shutdown, when php gets unloaded. Disabling php is a workaround for me, ignoring the error messages is another.

[Walter (wdoekes)]

Ok. That wasn't clear to me that I should've filed it in a different manner.

I see the error of my ways and will mark it as duplicate. I wonder who reads bugs for this package though, since apparently the Ubuntu guys don't.

> I'm seeing this during shutdown, when php gets unloaded.

That is odd indeed. stderr marked as buffered and not flushed until shutdown?