From owner-freebsd-current Wed Jan 27 15:45:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA01538 for freebsd-current-outgoing; Wed, 27 Jan 1999 15:45:33 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA01532 for ; Wed, 27 Jan 1999 15:45:29 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id PAA06079; Wed, 27 Jan 1999 15:43:19 -0800 (PST) (envelope-from sef) Date: Wed, 27 Jan 1999 15:43:19 -0800 (PST) From: Sean Eric Fagan Message-Id: <199901272343.PAA06079@kithrup.com> To: nate@mt.sri.com Subject: Re: "JAIL" code headed for -current. Cc: current@FreeBSD.ORG, julian@whistle.com In-Reply-To: <199901272333.QAA24533@mt.sri.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >But then we're still having an API change that doesn't have to be there. No, it's not. If you change suser() to: int suser(uc, ac) struct ucred *uc; u_short *ac; { return JAILsuser(0, uc, ac); } then suser() continues to have the same semantics and calling convention; you can speed this up a bit by having: #define suser(a,b) JAILsuser(0, a, b) in (where suser's prototype is). Then you can simply change the calls from suser() to JAILsuser() as needed. (Actually, JAILsuser is a bad name, really, since this could also be used to move to a more-capability-based mechanism, with the "jail" being simply one set of resources to compare the requested capability against. But that's just a thought that has occurred to me, and I haven't spent any time making it coherent ;).) Doing it this way should result in a superset, and minimal source code changes; doing it with just the stub routine would result in minimal binary impact as well. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message