From - Fri Oct 03 14:51:35 1997 From: markr@osr.com (Mark Roddy) Subject: Re: NT driver: access rights in IRP_MJ_CREATE Date: Fri, 03 Oct 1997 15:38:29 GMT Organization: OSR Open System Resources, Inc. References: <01bcc385$88925790$5c01a8c0@w_rt> <1997Sep17.115829.8186@cmkrnl> X-Newsreader: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3435113c.0@news.osr.com> Lines: 55 Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode,microsoft.public.win32.programmer.kernel Path: news.mitre.org!blanket.mitre.org!philabs!newsjunkie.ans.net!newsfeeds.ans.net!iagnet.net!204.73.178.14!visi.com!news-out.visi.com!uppssnewspub03.moswest.msn.net!uppssnewspub05.moswest.msn.net!news.osr.com!menemsha.osr.com Xref: news.mitre.org comp.os.ms-windows.programmer.nt.kernel-mode:3900 microsoft.public.win32.programmer.kernel:774 On 17 Sep 97 11:58:29 PST, jeh@cmkrnl.com (Jamie Hanrahan) wrote: > >In article <01bcc385$88925790$5c01a8c0@w_rt>, "Thomas Rummel" writes: >> Hi, >> >> I'm writing a NT device driver and have a problem with checking the >> desired access rights in the Create function (IRP_MJ_CREATE). >> >> Till now I used the field of the PIO_STACK_LOCATION >> (Parameters.Create.SecurityContext->AccessState->OriginalDesiredAccess) >> but Microsoft changed the value of this field with NT4 Service Pack 3 :-( >> >> My question: >> What is the right way to check the access rights desired from the caller in >> the >> Create function of a NT device driver? > >Most drivers don't bother - it's already been checked and passed, or >else your driver would never have been invoked in the first place. > Jamie is correct here, but perhaps his answer has some assumptions that need to be clarified. When a user process opens your driver's DEVICE_OBJECT, whatever security there is on the device object has already been checked for you. If your driver has some other securable object accessed indirectly through a user process NtCreateFile request, then you would indeed have to do security checking on _that_ object. For example, when you open a file in the NTFS file system the file system driver can assume that you have access to the underlying volume device object that was the direct target of the NtCreateFile operation. However the NTFS file system driver needs to know if you have access rights to the file on that volume device indicated by your open request. The "object" the NTFS FSD is going to check is not the volume device object, but the persistent security for the on-disk file contained by the target volume device. Each file and directory on an NTFS file system has its own security, and that is what the NTFS FSD is checking. The operating system has no way to generically perform per-file security checking on arbitrary file systems, so instead it divides the task up, giving file system drivers an interface to do security checking on files (or indeed on anything at all,) but making it the responsibility of file system drivers to do actually perform the checking when and if appropriate. -------------------------------------------------------------- Mark Roddy Consulting Associate OSR Open System Resources, Inc. 105 Route 101A, Suite 19 Amherst, NH 03031 (603) 595 6500 (voice) (603) 595 6503 (fax) http:\\www.osr.com markr@osr.com