[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
signature.asc
Description: This is a digitally signed message part.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- __libc_enable_secure & sgid to different own group,
Pino Toscano <=