From owner-freebsd-current Thu Mar 25 16:53:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from hun.org (hun.org [207.49.60.254]) by hub.freebsd.org (Postfix) with ESMTP id DA15C15259 for ; Thu, 25 Mar 1999 16:53:22 -0800 (PST) (envelope-from attila@hun.org) Received: from localhost (attila@localhost) by hun.org (8.9.2/8.9.2) with ESMTP id AAA22871; Fri, 26 Mar 1999 00:52:54 GMT (envelope-from attila@hun.org) Date: Fri, 26 Mar 1999 00:52:54 +0000 (GMT) From: attila Reply-To: attila@hun.org To: Sean Eric Fagan Cc: current@FreeBSD.ORG Subject: Re: "JAIL" code headed for -current. In-Reply-To: <199901272302.PAA02846@kithrup.com> Message-ID: Owner: attila@hun.org Organization: home for unpenitent hackers and anarcho-cryptophreaks Encrypted: NO MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just noticed the date on this discussion was two months ago; so I referenced the code in kern_prot.c which indicates no decision was made on this item.... was another solution implemented? actually, in a more deliberate consideration of the implications of changing the suser() call, I agree with Eric, but the concept, including assigning an exclusive internal IP number is important enough to warrant implementation, but maybe not with a revision to the suser() arguments. perhaps consider implementing a structure which each suser() call, and any function in the chroot() space, can reference which would contain the value of NOJAIL, the IP number, and whatever other parameters are discovered to be needed later. the structure can be added to any number of the sys/ group includes (all though it must be individually static to each icidence of chroot(). Eric's suggestion of the macro solves two problems: finding all incidents of suser(), and ancilliary code added later which might fail to notice the additional argument for which they would receive the expected response... int new_suser(chroot, cred, acflag) struct uchroot *chroot; struct ucred *cred; u_short *acflag; { if (chroot->nojail) return (EPERM); /* I presume this is the check */ if (cred->cr_uid == 0) { if (acflag) *acflag |= ASU; return (0); } return (EPERM); } I always have a preference to structures despite the extra reference --you can always add variables of any type as required. with the CPU speeds approaching nirvana, every new project is coded with a single stucture passed to each procedure; in many cases passing an element or two is more efficient, but it breaks the model. in general it is no more expensive on cpu time than unravelling a string of variables or structure elements being passed in the call since each has a backward reference. On Wed, 27 Jan 1999, Sean Eric Fagan wrote: *In article <199901271944.LAA15317.kithrup.freebsd.current@kithrup.com> you write: *>>all over the kernel: *>> *>> suser(NOJAIL, bla, bla); *>>or *>> suser(0, bla, bla); *>Oh, goody, more gratuitious incomaptibilities with everyone else. * *And to followup to my own message, since nobody else has: * *This is stupid. While I don't object to the concept (and even know people who *have requested it), that particular implementation sucks. It breaks an *existing API *and* ABI. * *I would suggest using a different routine name than suser(); suser() can be *made into a macro or stub routine that calls the new routine with a first *argument of 0 (or, of course, both a macro *and* a stub routine). * *Any time there's a change, "all over the kernel," THIS SHOULD RAISE WARNING *FLAGS, PEOPLE! * * *To Unsubscribe: send mail to majordomo@FreeBSD.org *with "unsubscribe freebsd-current" in the body of the message * __________________________________________________________________________ go not unto usenet for advice, for the inhabitants thereof will say: yes, and no, and maybe, and I don't know, and fuck-off. _________________________________________________________________ attila__ The more things change, the more they stay insane. To be a ruler of men, you need at least 12 inches.... There is no safety this side of the grave. Never was; never will be. __________________________________________________________________________ "Microsoft isn't evil, they just make really crappy Operating Systems" -Linus Torvalds __________________________________________________________________________ Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. - (c) 1999 Stan Brown. Redistribution via the Microsoft Network is prohibited. __________________________________________________________________________ (ASP) Microsoft Corporation (MSFT) announced today that the release of its productivity suite, Office 2000, will be delayed until the first quarter of 1901. __________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message