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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
