Relative open with a volume handle ?

Is it possible to use the relative open with NtCreateFile and a volume
handle; or is this strictly a file system concept? I want to reopen a
volume handle with different access permissions.

Regards,

George.

DougHowe
Mon Feb 14 18:49:45 CST 2005

------=_NextPart_0001_1D8D3C12
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hello George,

Are you trying to open the volume itself, or a file/directory on the
volume? Are you trying to use a volume handle as the RootDirectory in
OBJECT ATTRIBUTES?

Regards,
Doug Howe
Microsoft DDK Support

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_1D8D3C12
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Hello George,
\par
\par Are you trying to open the volume itself, or a file/directory on the volume? Are you trying to use a volume handle as the RootDirectory in OBJECT ATTRIBUTES?
\par
\par Regards,
\par Doug Howe
\par Microsoft DDK Support
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par }
------=_NextPart_0001_1D8D3C12--

George
Mon Feb 14 19:33:12 CST 2005

Doug,

> Are you trying to open the volume itself...<

Yes.

> Are you trying to use a volume handle as the RootDirectory in
> OBJECT ATTRIBUTES? <

Yes.

I have a situation where most of the time I need a volume handle opened with
zero access permissions but sometimes I encounter a situation where I need
greater access to the same volume. It would be nice if I could just
"reopen" the volume in the same way that you can with a directory or file
handle. But I guess the relative open is just not designed to work that
way. That is what I am trying to confirm.

Regards,

George.

Maxim
Tue Feb 15 07:49:22 CST 2005

Try DuplicateHandle.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"George M. Garner Jr." <gmgarner@newsgroup.nospam> wrote in message
news:OcljZrZEFHA.960@TK2MSFTNGP09.phx.gbl...
> Is it possible to use the relative open with NtCreateFile and a volume
> handle; or is this strictly a file system concept? I want to reopen a
> volume handle with different access permissions.
>
> Regards,
>
> George.
>
>

George
Tue Feb 15 15:26:29 CST 2005

Maxim,

> Try DuplicateHandle. <

ERROR_ACCESS_DENIED. Evidently you can de-escalate access permissions using
DuplicateHandle but you cannot escalate access permissions. There is
considerable merit to following the principle of least privilege when
accessing resources. Unfortunately MS makes that difficult in current
implementations. This is a design flaw.

Thanks anyway.

Regards,

George.

Peter
Tue Feb 15 15:47:25 CST 2005

if you think this is a design flaw then you've misunderstood the purpose of
DuplicateHandle. This creates a new handle to the same file object as the
previous one.

Since the security checks are made when the file object is opened, Windows
can't allow you to obtain greater access through the duplicate handle.

why is doing a relative open of the volume easier than just opening it again
with the same name?

-p

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"George M. Garner Jr." <gmgarner@newsgroup.nospam> wrote in message
news:eOztKU6EFHA.2700@TK2MSFTNGP14.phx.gbl...
> Maxim,
>
>> Try DuplicateHandle. <
>
> ERROR_ACCESS_DENIED. Evidently you can de-escalate access permissions
> using DuplicateHandle but you cannot escalate access permissions. There
> is considerable merit to following the principle of least privilege when
> accessing resources. Unfortunately MS makes that difficult in current
> implementations. This is a design flaw.
>
> Thanks anyway.
>
> Regards,
>
> George.
>
>
>

George
Tue Feb 15 17:09:51 CST 2005

Peter,

> why is doing a relative open of the volume easier than just opening it
> again
> with the same name? <

In a distributed computing environment, the component that needs to do the
reopen does not always have access to the string that originally was used to
open the "file." There are also numerous attributes and flags that would
have to be passed along with the file handle.

> Since the security checks are made when the file object is opened, Windows
> can't allow you to obtain greater access through the duplicate handle.

Your observation, while technically correct, assumes that MS is incapable of
performing access checks when additional access rights are required. A
limitation does not become a feature simply by changing its label. Perhaps
granting additional access rights fits better into the logic of ReOpenFile.
But that or's in FILE_NON_DIRECTORY_FILE create options. You can't even use
it with a directory handle more or less a volume handle.

In any event, a PERFORM_ACCESS_CHECKS flag for DuplicateHandle would be
extremely useful in a future release.

Regards,

George.

Maxim
Wed Feb 16 12:26:25 CST 2005

> ERROR_ACCESS_DENIED. Evidently you can de-escalate access permissions using
> DuplicateHandle but you cannot escalate access permissions. There is
> considerable merit to following the principle of least privilege when
> accessing resources. Unfortunately MS makes that difficult in current
> implementations. This is a design flaw.

??? Please suggest a safe way of escalating permissions via DuplicateHandle,
which will not be just plain a hole?

Not to say that FSD itself can remember that this file object is read-only, and
not build some structures necessary for writing for it. For instance, in UNIX,
these permissions are kept in file object and not in the handle.

Permissions are never escalated for a file object. Create another file object
by CreateFile if you need larger permissions.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Maxim
Wed Feb 16 12:32:26 CST 2005

So, save the filename string together with the open handle, and write your own
ReOpenFile with this structure. Very easy. Much easy then rewriting all FSDs
for MS's developers :)

Another way. Open with maximum access, then DuplicateHandle to small access,
and only use the duplicated handle in most work for minimal privileges.

> Your observation, while technically correct, assumes that MS is incapable of
> performing access checks when additional access rights are required.

Exactly.
All access checks are gathered to a point just before the access is granted.

> limitation does not become a feature simply by changing its label. Perhaps
> granting additional access rights fits better into the logic of ReOpenFile.

Such logic must be supported in all FSDs at least :-) writing 1 more code path
to any FSD just to satisfy the need of 0.001% of developers is really clumsy :)

> In any event, a PERFORM_ACCESS_CHECKS flag for DuplicateHandle would be
> extremely useful in a future release.

It will not be there. The FSDs do not support it. More so - I think no OS
supports this :)

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

George
Wed Feb 16 13:21:20 CST 2005

Maxim,

I am not particularly concerned with DuplicateHandle. It may well be that
ReOpenFile is a better construct for this than DuplicateHandle. (You are
the one who suggested DuplicateHandle btw.)

> Not to say that FSD itself can remember that this file object is
> read-only, and
> not build some structures necessary for writing for it. For instance, in
> UNIX,
> these permissions are kept in file object and not in the handle.

I am not sure what you are saying. I can escalate privileges on a file
system "file object" today using ReOpenFile which uses the relative open
internally with a null trailing string. Every Windows "object" stores a
reference to the object's security descriptor. Every calling process stores
a reference to the caller's SID. With these two pieces of information you
can perform an access check. Whether or not you should be able to do the
same thing using the DuplicateHandle concept is debatable but it certainly
could be done.

> that this file object is read-only <

Again I am not sure what you are saying. Are you asserting that it is not
possible to look up current file system access permissions using a reference
to an existing "file object?" Then how does GetFileInformationByHandle
work? Here is the definition of BY_HANDLE_FILE_INFORMATION.

typedef struct _BY_HANDLE_FILE_INFORMATION {
DWORD dwFileAttributes;
FILETIME ftCreationTime;
FILETIME ftLastAccessTime;
FILETIME ftLastWriteTime;
DWORD dwVolumeSerialNumber;
DWORD nFileSizeHigh;
DWORD nFileSizeLow;
DWORD nNumberOfLinks;
DWORD nFileIndexHigh;
DWORD nFileIndexLow;
} BY_HANDLE_FILE_INFORMATION,
*PBY_HANDLE_FILE_INFORMATION;

Are you saying that all of this is stored in the 4-byte access member of a
file handle?

Regards,

George.

Maxim
Wed Feb 16 15:08:01 CST 2005

> I am not sure what you are saying. I can escalate privileges on a file
> system "file object" today using ReOpenFile which uses the relative open
> internally with a null trailing string.

Have you tried? IIRC at least some filesystems require the related file to be a
directory. I may be wrong in this.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

DougHowe
Mon Feb 21 16:00:20 CST 2005

------=_NextPart_0001_40FF0153
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

George,

You might consider opening the volume for at least read and write
attributes (FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES) when you open the
volume, otherwise you will be opening the storage stack device.

Regards,
Doug Howe
Microsoft DDK Support

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_40FF0153
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}{\f1\fmodern\fprq1\fcharset0 Courier New;}}
\viewkind4\uc1\pard\f0\fs20 George,
\par
\par You might consider opening the volume for at least read and write attributes (\f1 FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES\f0 ) when you open the volume, otherwise you will be opening the storage stack device.
\par
\par Regards,
\par Doug Howe
\par Microsoft DDK Support
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par }
------=_NextPart_0001_40FF0153--

George
Sat Feb 26 02:08:11 CST 2005

Doug,

I will keep this in mind for the future. However at the moment it is a moot
issue since there is no way, official or unofficial to upgrade a volume
handle, short of closing the original handle and reopening it with added
privileges.

In my specific application opening the volume handle with zero access
permissions is useful because a limited user is able to open the handle in
this manner and retrieve volume extents
(IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS) and other volume information
(GetVolumeInformation()) even without additional privileges. Initially
opening the handle with minimum privileges allows the application to degrade
gracefully and provide a good deal of useful information even if you find
your self logged on to a limited account. Upgrading the volume handle then
permits an administrator to obtain additional information that requires
FILE_READ_DATA permission, e.g. FSCTL_GET_NTFS_VOLUME_DATA.

Assuming for the sake of argument that upgrading a volume or directory
handle is addressed in the future, through ReOpenFile or through some other
function, it would be for the implementation to be aware of and handle this
case.

Regards,

George.

"Doug Howe [MSFT]" <DougHowe@online.microsoft.com[MSFT]> wrote in message
news:gINjDDGGFHA.296@TK2MSFTNGXA02.phx.gbl...
> George,
>
> You might consider opening the volume for at least read and write
> attributes (FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES) when you open
> the
> volume, otherwise you will be opening the storage stack device.
>
> Regards,
> Doug Howe
> Microsoft DDK Support
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.

DougHowe
Tue Mar 01 13:50:15 CST 2005

------=_NextPart_0001_15482FB7
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

George,

I understand and appreciate your situation. Thanks for explaining your
requirements -- you have generated some good discussion.

Regards,
Doug Howe
Microsoft DDK Support

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_15482FB7
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 George,
\par
\par I understand and appreciate your situation. Thanks for explaining your requirements -- you have generated some good discussion.
\par
\par Regards,
\par Doug Howe
\par Microsoft DDK Support
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par }
------=_NextPart_0001_15482FB7--