[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hurd-bug
Subject:    __libc_enable_secure & sgid to different own group
From:       Pino Toscano <toscano.pino () tiscali ! it>
Date:       2015-06-27 12:03:08
Message-ID: 2085255.hug9X9jSIo () drak
[Download RAW message or body]


Hi,

While debugging p11-kit, I found out a different behaviour of
__libc_enable_secure between Linux and Hurd. In particular:

$ cat <<EOF >frob-gid.c
#include <stdio.h>

int main(void)
{
  extern int __libc_enable_secure;
  printf("__libc_enable_secure = %d\n", __libc_enable_secure);
  return 0;
}
EOF
$ cc -o frob-gid frob-gid.c
$ ./frob-gid
__libc_enable_secure = 0

Now we make frob-gid sgid, using another of the groups of the current
user:

$ groups
users dialout [...]
$ chown $(id -nu).dialout frob-gid
$ chmod g+s frob-gid

At this point, the output of frob-gid is 1 on Linux, while 0 on Hurd.

__libc_enable_secure is set by checking for the EXEC_SECURE flag, which 
e.g. diskfs_S_file_exec sets before calling exec_exec. Reading 
fshelp_exec_reauth makes me think this behaviour is somehow wanted, and 
this code (except fixes like 913d709e1) is basically doing that way for
decades.

p11-kit uses __libc_enable_secure in its replacement for
getauxval(AT_SECURE), falling back to issetugid (which we don't have)
and then to getresuid (which we have).

I don't have much knowledge in how this behaviour should be, so
a) the current Hurd behaviour is fine and conformant, so p11-kit should
   avoid using __libc_enable_secure for getauxval(AT_SECURE)
b) the behaviour is wrong and should be fixed in Hurd
?

Thanks,
-- 
Pino Toscano
["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]