FILE_OPEN_FOR_BACKUP_INTENT

Thanks to everyone for their patience with this one.
I know posting to both boards asking about FILE_OPEN_FOR_BACKUP_INTENT
is not in keeping with the spirit of the boards, but since I am also
responsible for
a FSD, well, as they say, there is my quandary.

The MSDN states that this CreateOption is “…irrelevant to device and
intermediate drivers”.
(ref.
http://msdn2.microsoft.com/en-us/library/bb432380(VS.85).aspx)
OSRonline states that this CreateOption means
“The file is being opened for backup intent, hence, the
system should check for
certain access rights and grant the caller the
appropriate accesses to the file before
checking the input DesiredAccess against the file’s
security descriptor.
This flag is irrelevant to device and intermediate drivers.”
(ref. http://www.osronline.com/DDKx/kmarch/k111_9dte.htm)
Another place in the MSDN has similar wording to the OSR statement.

Basically my questions are:

  1. Is it true: If certain access rights are checked, then the access
    actually granted to the file/directory for this
    open could result in “Write” access granted even though “Write”
    was not specified in DesireAccess.
  2. As an FSD, what / where are these “certain access rights” and how
    do I map / compare them
    (or do I) against the Disposition, Options, and DesiredAccess
    requested in the file/directory Open?
    Thanks
    Duane

Have you looked at FastFat? It is a standard FSD with some security in that types of creates. I have not looked, but the write of attributes is appropriate for a backup utility and during restore a write of the data should be permitted. A user must have backup rights and when those are granted, they have more access to the filesystem than almost any user. That is why correct usage of privileges is important.
“Duane Souder” wrote in message news:xxxxx@ntfsd…
Thanks to everyone for their patience with this one.
I know posting to both boards asking about FILE_OPEN_FOR_BACKUP_INTENT
is not in keeping with the spirit of the boards, but since I am also responsible for
a FSD, well, as they say, there is my quandary.

The MSDN states that this CreateOption is “…irrelevant to device and intermediate drivers”.
(ref. http://msdn2.microsoft.com/en-us/library/bb432380(VS.85).aspx)
OSRonline states that this CreateOption means
“The file is being opened for backup intent, hence, the system should check for
certain access rights and grant the caller the appropriate accesses to the file before
checking the input DesiredAccess against the file’s security descriptor.
This flag is irrelevant to device and intermediate drivers.”
(ref. http://www.osronline.com/DDKx/kmarch/k111_9dte.htm)
Another place in the MSDN has similar wording to the OSR statement.

Basically my questions are:
1) Is it true: If certain access rights are checked, then the access actually granted to the file/directory for this
open could result in “Write” access granted even though “Write” was not specified in DesireAccess.
2) As an FSD, what / where are these “certain access rights” and how do I map / compare them
(or do I) against the Disposition, Options, and DesiredAccess requested in the file/directory Open?
Thanks
Duane

David,
Thanks for the reply. I just checked the fastfat source from the vista
ddk and
file_open_for_backup_intent is not used in fastfat.
Can anyone shed some light on this issue ?
Can anyone from Microsoft comment ?
Thanks,
Duane Souder
Cisco Systems Inc.

David Craig wrote:

Have you looked at FastFat? It is a standard FSD with some security
in that types of creates. I have not looked, but the write of
attributes is appropriate for a backup utility and during restore a
write of the data should be permitted. A user must have backup rights
and when those are granted, they have more access to the filesystem
than almost any user. That is why correct usage of privileges is
important.

“Duane Souder” >
> wrote in message news:xxxxx@ntfsd…
> Thanks to everyone for their patience with this one.
> I know posting to both boards asking about FILE_OPEN_FOR_BACKUP_INTENT
> is not in keeping with the spirit of the boards, but since I am
> also responsible for
> a FSD, well, as they say, there is my quandary.
>
> The MSDN states that this CreateOption is “…irrelevant to device
> and intermediate drivers”.
> (ref.
> http://msdn2.microsoft.com/en-us/library/bb432380(VS.85).aspx)
> OSRonline states that this CreateOption means
> “The file is being opened for backup intent, hence,
> the system should check for
> certain access rights and grant the caller the
> appropriate accesses to the file before
> checking the input DesiredAccess against the file’s
> security descriptor.
> This flag is irrelevant to device and intermediate
> drivers.”
> (ref.
> http://www.osronline.com/DDKx/kmarch/k111_9dte.htm)
> Another place in the MSDN has similar wording to the OSR statement.
>
> Basically my questions are:
> 1) Is it true: If certain access rights are checked, then the
> access actually granted to the file/directory for this
> open could result in “Write” access granted even though
> “Write” was not specified in DesireAccess.
> 2) As an FSD, what / where are these “certain access rights” and
> how do I map / compare them
> (or do I) against the Disposition, Options, and
> DesiredAccess requested in the file/directory Open?
> Thanks
> Duane
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Can’t say as I’ve explored deeply, but I have used
FILE_OPEN_FOR_BACKUP_INTENT as far as I’m aware it effectively means
that you have no write access on the file.

Of course, in using it I wasn’t interested in checking or using write access.

As for the access rights, the calling process must have the
SeBackupPrivilege set.

HTH,

Mark.

At 21:28 14/05/2008, you wrote:

David,
Thanks for the reply. I just checked the fastfat source from the
vista ddk and
file_open_for_backup_intent is not used in fastfat.
Can anyone shed some light on this issue ?
Can anyone from Microsoft comment ?
Thanks,
Duane Souder
Cisco Systems Inc.

David Craig wrote:
>Have you looked at FastFat? It is a standard FSD with some
>security in that types of creates. I have not looked, but the
>write of attributes is appropriate for a backup utility and during
>restore a write of the data should be permitted. A user must have
>backup rights and when those are granted, they have more access to
>the filesystem than almost any user. That is why correct usage of
>privileges is important.
>“Duane Souder” <mailto:xxxxxxxxxx@cisco.com> wrote
>>in message news:xxxxxnews:xxxxx@ntfsd…
>>Thanks to everyone for their patience with this one.
>>I know posting to both boards asking about FILE_OPEN_FOR_BACKUP_INTENT
>>is not in keeping with the spirit of the boards, but since I am
>>also responsible for
>>a FSD, well, as they say, there is my quandary.
>>
>>The MSDN states that this CreateOption is “…irrelevant to device
>>and intermediate drivers”.
>> (ref.
>> http:http://msdn2.microsoft.com/en-us/library/bb432380(VS.85).aspx)
>>OSRonline states that this CreateOption means
>> “The file is being opened for backup intent, hence,
>> the system should check for
>> certain access rights and grant the caller the
>> appropriate accesses to the file before
>> checking the input DesiredAccess against the file’s
>> security descriptor.
>> This flag is irrelevant to device and intermediate drivers.”
>> (ref.
>> http:http://www.osronline.com/DDKx/kmarch/k111_9dte.htm)
>>Another place in the MSDN has similar wording to the OSR statement.
>>
>>Basically my questions are:
>>1) Is it true: If certain access rights are checked, then the
>>access actually granted to the file/directory for this
>> open could result in “Write” access granted even
>> though “Write” was not specified in DesireAccess.
>>2) As an FSD, what / where are these “certain access rights” and
>>how do I map / compare them
>> (or do I) against the Disposition, Options, and
>> DesiredAccess requested in the file/directory Open?
>>Thanks
>>Duane
>>
>>
>>
>>—
>>NTFSD is sponsored by OSR
>>
>>For our schedule debugging and file system seminars
>>(including our new fs mini-filter seminar) visit:
>>http:http://www.osr.com/seminars
>>
>>You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
>>To unsubscribe send a blank email to
>>mailto:xxxxxxxxxx@lists.osr.com
>
>
>—
>NTFSD is sponsored by OSR
>
>For our schedule debugging and file system seminars
>(including our new fs mini-filter seminar) visit:
>http://www.osr.com/seminars
>
>You are currently subscribed to ntfsd as: xxxxx@muttsnuts.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></http:></http:></http:></news:xxxxx></mailto:xxxxx>

When you use open for backup intent you must have SeBackupPrivilege and SeRestorePrivilige (if you need to restore files). You will not get write access if you did not ask for it but if you do ask for write access the file system will check that you have SeRestorePrivilege. If you do then you can open for write even if the user would not normally have write access (SeRestorePrivilege must be requested by the process using open for backup and the user must be allowed to set it). As far as I know the “certain access rights” mentioned in the documents would be the backup and restore privileges.

> file_open_for_backup_intent is not used in fastfat

. and rightly so: the purpose is to save all streams in a backup, and FAT
(as opposed to NTFS) does not have any.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Duane Souder
Sent: Wednesday, May 14, 2008 4:28 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FILE_OPEN_FOR_BACKUP_INTENT

David,
Thanks for the reply. I just checked the fastfat source from the vista ddk
and
file_open_for_backup_intent is not used in fastfat.
Can anyone shed some light on this issue ?
Can anyone from Microsoft comment ?
Thanks,
Duane Souder
Cisco Systems Inc.

David Craig wrote:

Have you looked at FastFat? It is a standard FSD with some security in that
types of creates. I have not looked, but the write of attributes is
appropriate for a backup utility and during restore a write of the data
should be permitted. A user must have backup rights and when those are
granted, they have more access to the filesystem than almost any user. That
is why correct usage of privileges is important.

“Duane Souder” wrote in message news:xxxxx@ntfsd…

Thanks to everyone for their patience with this one.
I know posting to both boards asking about FILE_OPEN_FOR_BACKUP_INTENT
is not in keeping with the spirit of the boards, but since I am also
responsible for
a FSD, well, as they say, there is my quandary.

The MSDN states that this CreateOption is “…irrelevant to device and
intermediate drivers”.
(ref.
http://msdn2.microsoft.com/en-us/library/bb432380(VS.85
http: ).aspx)
OSRonline states that this CreateOption means
“The file is being opened for backup intent, hence, the system
should check for
certain access rights and grant the caller the appropriate
accesses to the file before
checking the input DesiredAccess against the file’s security
descriptor.
This flag is irrelevant to device and intermediate drivers.”
(ref. http://www.osronline.com/DDKx/kmarch/k111_9dte.htm)
Another place in the MSDN has similar wording to the OSR statement.

Basically my questions are:
1) Is it true: If certain access rights are checked, then the access
actually granted to the file/directory for this
open could result in “Write” access granted even though “Write” was
not specified in DesireAccess.
2) As an FSD, what / where are these “certain access rights” and how do I
map / compare them
(or do I) against the Disposition, Options, and DesiredAccess
requested in the file/directory Open?
Thanks
Duane


NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com</http:>

> Thanks for the reply. I just checked the fastfat source from the vista

ddk and
file_open_for_backup_intent is not used in fastfat.

This flag only influences the access rights checking on NTFS.

Since FAT has no file access rights, it ignores this flag.


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

> . and rightly so: the purpose is to save all streams in a backup, and FAT

(as opposed to NTFS) does not have any.

No, its about the ACLs.

In “backup intent” open, the SeBackup/RestorePrivilege must be on, but the file
ACL is just ignored.

FAT has no ACLs.


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

This flag is also set when a user mode folder monitor is on, reading directory changes with ReadDirectoryChangesW. The handle passed to ReadDirectoryChangesW should be open with this flag, so it is only somekind of state flag.

> No, its about the ACLs.
It is true that MSDN says that in FILE_OPEN_FOR_BACKUP_INTENT case
" … the system should check for certain access rights and grant
the caller the appropriate access to the file-before checking the
DesiredAccess parameter against the file’s security descriptor.
This flag not used by device and intermediate drivers."

But what are these “certain access rights”, why are they
have to be checked and for what purpose? The answer is in the
description of BackupRead API, which sits on top and “processes all
of the data pertaining to an opened object as a series of
discrete byte streams. Each stream is preceded by a 32-bit
aligned WIN32_STREAM_ID structure.”

Now it becomes clear why these “certain access rights” are
so special.

It is about ADSes. ACLs are a consequence, not the reason.

I wish the docs would add a word or two to " not used by
device and intermediate drivers."

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-324335-
xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, May 15, 2008 12:16 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FILE_OPEN_FOR_BACKUP_INTENT

> . and rightly so: the purpose is to save all streams in a backup, and
FAT
> (as opposed to NTFS) does not have any.

No, its about the ACLs.

In “backup intent” open, the SeBackup/RestorePrivilege must be on, but
the file
ACL is just ignored.

FAT has no ACLs.


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


NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

> But what are these “certain access rights”, why are they

have to be checked and for what purpose? The answer is in the
description of BackupRead API

You can open file for backup and use ReadFile instead of BackupRead, the ACLs
will still be ignored.


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