Discussion:
ZwQuerySecurityObject, FltQuerySecurityObject, ObGetObjectSecurity returning ACCESS DENIED on a network share file.
(too old to reply)
matt_sykes
2010-08-24 09:45:05 UTC
Permalink
Hi all. Havent posted here for a while, but I wanted your opinion on
this issue. The codes OK, on local files these functions are fine,
but they all return DENIED on a network shared file.

There is an SMB2 conversation during this process with a
QUERY_INFORMATION Class=FileInfo sent to the system with the share,
which responds with STATUS_ACCESS_DENIED QUERY_INFORMATION.

From reading up in SMB (Microsoft call it CIFS) I saw this: "Each
server makes a set of shared resources available to clients on the
network. A resource being shared may be a directory tree, a printer, a
named pipe, or other object. The CIFS protocol requires server
authentication of users before resource accesses are allowed. Each
server authenticates its own users."

I imagine the problem is because the kernel has not been authorised in
the same way as the shell once the user owning that share has logged
on. What is your take on this?

Thx
Maxim S. Shatskih
2010-08-24 19:45:31 UTC
Permalink
Post by matt_sykes
I imagine the problem is because the kernel has not been authorised in
the same way as the shell once the user owning that share has logged
on. What is your take on this?
Your kernel code must be in the correct user thread context to make such SMB calls.
--
Maxim S. Shatskih
Windows DDK MVP
***@storagecraft.com
http://www.storagecraft.com
matt_sykes
2010-08-25 06:35:01 UTC
Permalink
Post by Maxim S. Shatskih
Post by matt_sykes
I imagine the problem is because the kernel has not been authorised in
the same way as the shell once the user owning that share has logged
on.  What is your take on this?
Your kernel code must be in the correct user thread context to make such SMB calls.
--
Maxim S. Shatskih
Windows DDK MVP
Thought so. Unfortunately its called by a service, which runs in the
system account. I had thought of this already though but thanks for
verifying it.

In another product we hooked NtCreateTokan in order to do
impersonation but this isnt in this product.
Pavel A.
2010-08-25 10:09:47 UTC
Permalink
"matt_sykes" <***@hotmail.com> wrote in message
news:fd566716-1ac7-403d-ad82-
........
Post by matt_sykes
In another product we hooked NtCreateTokan in order to do
impersonation but this isnt in this product.
That's good - no need to repeat the traditional mantras about hooking :)

-- pa
matt_sykes
2010-08-25 11:44:26 UTC
Permalink
Post by Pavel A.
news:fd566716-1ac7-403d-ad82-
........
Post by matt_sykes
In another product we hooked NtCreateTokan in order to do
impersonation but this isnt in this product.
That's good - no need to repeat the traditional mantras about hooking :)
-- pa
:) We found a 2003 server bug doing this a few months back.
matt_sykes
2010-08-25 12:05:36 UTC
Permalink
Post by Maxim S. Shatskih
Post by matt_sykes
I imagine the problem is because the kernel has not been authorised in
the same way as the shell once the user owning that share has logged
on.  What is your take on this?
Your kernel code must be in the correct user thread context to make such SMB calls.
--
Maxim S. Shatskih
Windows DDK MVP
I had a little play with calling the code from the kernel in a user
thread context (in a deviceioctl handler) and ZwQuerySecurityObject()
still returns ACCESS_DENIED. Did you have a different user thread
context in mind?

Loading...