A question about ipcperm() call?

Robert Watson rwatson at FreeBSD.org
Mon Jul 24 12:04:48 UTC 2006

On Mon, 24 Jul 2006, Xin LI wrote:

>> why not directly return the error in line 94?
> I think it makes sense to remove the assignment and the 'error' variable. 
> Let's see Robert's opinion.

I'm sorry, my previous answer was based on a mis-reading of the question -- 
you're not suggesting returning EPERM directly, rather, avoiding the "fall 
out" to the return (0).

ipcperm() is not very well structured, in part because the access control 
logic itself isn't very well structured.  Normally I try to structure access 
control functions so that we check all the possible reasons not to grant a 
request, and return (0) only if they all pass, returning various errors along 
the way.  This works well in many cases because we often have lots of reasons 
not to allow something, and few reasons to allow it.  For example, the 
p_checkfoo() inter-process access control checks.  However, when discretionary 
access control is present, things get a little more complex, since the first 
task is to identify which set of rules are required, then to compose the 
mandatory rules, matching discretionary rules, and privilege.  This is true in 
vaccess() and vaccess_acl_posix1e(), and should be true in ipcperm() also.  I 
would be interested in seeing reasonable restructurings of this code, perhaps 
as a set of blocks that looks at each requested operation or set of related 
operations and authorizes them sequentially.

Robert N M Watson
Computer Laboratory
University of Cambridge

More information about the freebsd-hackers mailing list