Date: Fri, 26 Mar 1999 00:52:54 +0000 (GMT) From: attila <attila@hun.org> To: Sean Eric Fagan <sef@kithrup.com> Cc: current@FreeBSD.ORG Subject: Re: "JAIL" code headed for -current. Message-ID: <Pine.BSF.4.05.9903252311150.22565-100000@hun.org> In-Reply-To: <199901272302.PAA02846@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9903252311150.22565-100000>