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

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 16, 2006 at 01:00:56PM +0000, Robert Watson wrote:
> Only if IPC_M is being requested.  Is IPC_M being requested in the case 
> where you are seeing an error?  I can read code too, so what I'm asking is 
> how the system is behaving.

I'll track exact case a bit later. For now I just speak about differences 
between new code and old code I found. New code check all bits match while 
old code check IPC_M bit match only at this place.

> is requested.  We grant valid rights, not all rights, to the super user.  

This is clearly wrong.
Think about files. Even file is read-only, root _can_ write into it while 
normal user in the same situation can't.

root> touch aaa
root> chmod 444 aaa
root> cat > aaa
OK
^D

> As I said, this is something that I hope to revisit in the next few days. 
> However, it would be helpful if you could tell me the arguments and call 
> path to the ipcperm() function instance that's generating the improper 
> failure. It could be that both a bug in ipcperm() and a big in shmget() 

I'll try to make ktrace output, a bit later.

-- 
http://ache.pp.ru/



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