Bill Anderson <[EMAIL PROTECTED]> wrote:
>Kip Rugger wrote:
>> Chris McDonough <[EMAIL PROTECTED]> wrote:
>> >Aplogies for the ignorance, but can you maybe explain the concept
>> >of supplemental group ids and give an example of how the current unpatched
>> >behavior could be subverted?
>> I can try...
>> Supplemental gids are useful for allowing a user to belong to more
>> than one group, or maybe to more than one project in normal parlance.
>> This is normally effected by listing the uid opposite more than one
>> group in /etc/group. The login process issues the initgroups(3) call
>> to install these supplemental groups, which are inherited by all
>> processes forked from the login shell.
>> The problem is comes when you change user ids; for example what I
>> saw with Zope (start -u nobody) was:
>> before change after change
>> ============= ============
>> user id root nobody
>> group id root nobody
>> sup id(s) root root
>Would you mind describing how you determine this?
[/proc] $ cat /proc/90/status
State: S (sleeping)
Uid: 101 101 101 101
Gid: 101 101 101 101
Groups: 101 <------------------------------ supplemental groups
VmSize: 1348 kB
VmLck: 0 kB
VmRSS: 436 kB
VmData: 192 kB
VmStk: 84 kB
VmExe: 92 kB
VmLib: 952 kB
On my machine 101 is uid and gid for nobody; as you can see
junkbuster is correctly sandboxed. For unmodified Zope, you'll
see a zero in the indicated line (or possibly several values
if root belongs to several groups like `wheel' on your system).
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -