bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

__libc_enable_secure & sgid to different own group


From: Pino Toscano
Subject: __libc_enable_secure & sgid to different own group
Date: Sat, 27 Jun 2015 14:03:08 +0200
User-agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )

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

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]