Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Dec 2006 12:11:05 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Andrey Chernov <ache@FreeBSD.org>
Cc:        current@FreeBSD.org
Subject:   Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -current)
Message-ID:  <20061216120746.E72986@fledge.watson.org>
In-Reply-To: <20061216114426.GA7735@nagual.pp.ru>
References:  <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> <20061216114426.GA7735@nagual.pp.ru>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sat, 16 Dec 2006, Andrey Chernov wrote:

> See t-shm.c code in either dk-milter or dkim-milter to gather the sample of 
> operation. Those test written in way to be passed in all sysv ipc conformant 
> machines. Which isn't our FreeBSD now :(
>
> I think removing that old code is the root of the problem:
>
>                 * Always permit the creator/owner to update the object
>                 * protections regardless of whether the object mode
>                 * permits it.
>                 */
>                if (mode & IPC_M)
>                        return (0);
>
> I.e. old code not even check for IPC_W or IPC_R in case of IPC_M presense.

Is this conclusion a supposition or the result of testing?  Could you test and 
see if this is true?

> Moreover, old code allows _anything_ for suser:

The new code should also allow anything, as long as the bits passed into 
ipcperm() as requested modes are valid.  There's certainly a bug here 
somewhere, but I'm not convinced it's what you think it is.  At least part of 
the bug appears to be improper enforcement in the case of shmget() on an 
existing object, which is a bug in sysv_shm.c, not sysv_ipc.c.  I'll try to 
take a further look at this while on my way to Oxford today, but will be 
offline for a day or two so it may take me a bit to get back on this.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
>        if ((mode & perm->mode) != mode) {
>                if (suser(td) != 0)
>                        return (EACCES);
> 	}
>
>>> On Sat, Dec 16, 2006 at 08:59:03AM +0300, Andrey Chernov wrote:
>>>> It seems shm is broken in very recent -current.
>>>> Trying to build dkim-milter or dk-milter port (from root, of course) I
>>>> got:
>>>>
>>>> ./t-shm
>>>> shmget: Permission denied
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> shminit failed: Permission denied
>>>> 1..bad! t-shm.c:260 r == 0
>>>> add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4
>>>> and start over.
>>>> 0 of 1 tests completed successfully
>>>> *** 1 error in test! ***
>>>> 2..bad! t-shm.c:177 cnt <= MAX_CNT
>>>> add -DSM_CONF_SHM=0 to confENVDEF in devtools/Site/site.config.m4
>>>> and start over.
>>>> 4 of 5 tests completed successfully
>>>> *** 1 error in test! ***
>>>
>>>
>>> --
>>> http://ache.pp.ru/
>>>
>
>
> -- 
> http://ache.pp.ru/
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061216120746.E72986>