From owner-freebsd-arch Mon Feb 5 2:12: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lndsmtp01.ico.com (unknown [212.57.217.43]) by hub.freebsd.org (Postfix) with ESMTP id 23E0737B401; Mon, 5 Feb 2001 02:11:41 -0800 (PST) Received: from lndgate01.ico.com (unverified) by lndsmtp01.ico.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 5 Feb 2001 09:48:55 +0000 Received: from zoo.co.uk (212.57.223.232 [212.57.223.232]) by lndgate01.ico.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CRG16CS5; Mon, 5 Feb 2001 09:53:40 -0000 Message-ID: <3A7E767B.6AADB3B5@zoo.co.uk> Date: Mon, 05 Feb 2001 09:46:35 +0000 From: Nathan Gould X-Mailer: Mozilla 4.75 [en] (X11; U; OpenBSD 2.8 i386) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Tests for NULL p_ucred under p_cred -- are they needed? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: > I've noticed that at various points in the kernel code, there are tests to > check that the ucred structure in a proc is non-NULL before using it. > Under what circumstances do we believe it is possible for the ucred > pointer to be non-NULL? It seems that, in normal usage, it should always > be defined--the only points where it might be NULL would be during process > creation and process exit. Are these windows long enough for it to be a > concern? Are appropriate process locks held, under SMPng, such that it's > never possible to grab a ucred structure for a process while it is NULL? > > It seems that there are other components of the code that assume that if > (p) is non-NULL, then a ucred must be defined for the process, which seems > like a consistent assumption assuming appropriate protections are in > place. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message Surely, if for no other reason, we should be checking for abnormalities such as non-Null for security reasons i.e. security breaches tend to be based on non-corformance to publicised identified usage. Just a thought... Nathan Gould ngould@zoo.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message