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

List:       hurd-bug
Subject:    Re: __libc_enable_secure & sgid to different own group
From:       Samuel Thibault <samuel.thibault () gnu ! org>
Date:       2015-07-01 23:35:18
Message-ID: 20150701233518.GT3245 () type ! home
[Download RAW message or body]

Hello,

Pino Toscano, le Sat 27 Jun 2015 14:03:08 +0200, a écrit :
> $ 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.

So the user was actually already part of the dialout group?

Then I'd say we indeed have no reason to set __libc_enable_secure to 1:
there is no privilege escalation here, so no reason to disable any
features (which is the consequence of __libc_enable_secure being 1)

> 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)

For me getauxval(AT_SECURE) should also return 0 in this case, since
there is no privilege escalation.

Samuel

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