Pretend a file as read-only

NTFSD
1

Hi,

Does anyone know how to “mask” a file with a assigned access right?

I know that the application will be able to collect the access right of a file through IRP_MJ_CREATE. However, its access right can not be modified. It makes it difficult to pretend a file as read-only through a mini-filter, for example.

Introducing any idea will be highly appreciated.

Best regards,

2

If the create request includes write access deny the create.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, June 04, 2009 9:38 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Pretend a file as read-only

Hi,

Does anyone know how to “mask” a file with a assigned access right?

I know that the application will be able to collect the access right of a
file through IRP_MJ_CREATE. However, its access right can not be modified.
It makes it difficult to pretend a file as read-only through a mini-filter,
for example.

Introducing any idea will be highly appreciated.

Best regards,

NTFSD is sponsored by OSR

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

Sadly Bill, as simple as that sounds, it turns out that applications
that do not modify the file will fail to open it. Application
programmers are a sloppy lot and often ask for write access, even if
they have no intention of writing the file. While rejecting such
creates DOES make a read-only mini-filter, it is often pragmatically
unusable as a result.

When you try to build a read-only filter, you do have several possible
choices:

  • refuse all open for write cases; this suffers from application
    compatibility problems, but it does work.
  • allow open for write, but fail the actual write operations; this
    generally kills applications that write on the file. Note that you’ll
    also need to block memory mappings, since those you cannot do much
    about.
  • allow open for write and just discard the write operations.
    Applications are quite happy, even though the data never really makes it
    to disk.

Another thing to keep in mind is that even if the file is opened for
read there are NO guarantees that the file system won’t write data to
the disk (ergo, blocking I/O on a file is not the same as blocking it on
the volume.) For example, the file system might update the last access
time of the file. For a file system like NTFS this involves a write to
the MFT and the log.

Almost nothing in this business is as easy as it sounds.

Tony
OSR

4

And don’t forget the maximum allowed case. Also the file can be created or
overwritten based on the disposition even if only read access is requested.

You can also remove write access from the granted access in the post create.
The result will be similar to failing the write request except that the
handle will not have write access in it and the write will be denied by the
io manager before it gets to the file system.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Thursday, June 04, 2009 11:08 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Pretend a file as read-only

Sadly Bill, as simple as that sounds, it turns out that applications that do
not modify the file will fail to open it. Application programmers are a
sloppy lot and often ask for write access, even if they have no intention of
writing the file. While rejecting such creates DOES make a read-only
mini-filter, it is often pragmatically unusable as a result.

When you try to build a read-only filter, you do have several possible
choices:

  • refuse all open for write cases; this suffers from application
    compatibility problems, but it does work.
  • allow open for write, but fail the actual write operations; this generally
    kills applications that write on the file. Note that you’ll also need to
    block memory mappings, since those you cannot do much about.
  • allow open for write and just discard the write operations.
    Applications are quite happy, even though the data never really makes it to
    disk.

Another thing to keep in mind is that even if the file is opened for read
there are NO guarantees that the file system won’t write data to the disk
(ergo, blocking I/O on a file is not the same as blocking it on the volume.)
For example, the file system might update the last access time of the file.
For a file system like NTFS this involves a write to the MFT and the log.

Almost nothing in this business is as easy as it sounds.

Tony
OSR

NTFSD is sponsored by OSR

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

Hi Tony!

allow open for write, but fail the actual write operations; this
generally kills applications that write on the file. Note that you’ll
also need to block memory mappings, since those you cannot do much
about.
[Ayush Gupta] Are you suggesting to DISALLOW the files from getting mapped?
Do you suggest that we filter the IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHROIZATION
and fail the calls coming with PAGE_xxxWRITE flags?

Regards,
Ayush Gupta

6

>that do not modify the file will fail to open it. Application

programmers are a sloppy lot and often ask for write access, even if
they have no intention of writing the file.

Then these malwritten apps will fail on UAC on admin-only files.

  • allow open for write and just discard the write operations.
    Applications are quite happy,

Yes, databases which do log replays especially :-))))

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

7

> [Ayush Gupta] Are you suggesting to DISALLOW the files from getting mapped?

The section object IIRC contains only 2 fields: reference to MmCa control area (which is the actual section object core, 0 or 1 per FCB) and the allowed page protection flags.

CreateFileMapping/NtCreateSection will check for proper access on the provided file handle and will fail early if you try to make writable (not COW) mapping on a file handle which has no write access granted, the similar thing is also works for execute access. The allowed page protection flags from the call parameter are saved to the section object.

Then, MapViewOfFile will check the requested page protection flags against the one in the section object, and, on success, will create the VAD which will hold a reference to MmCa directly, section object is no more needed IIRC.

So, to block writable mappings, you need to disallow the write access in the file handle in CreateFile path.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

8

Hi Maxim,

So, to block writable mappings, you need to disallow the write access in
the file handle in CreateFile path.

[Ayush Gupta] Tony mentioned in his post that " allow open for write, but
fail the actual write operations; this generally kills applications that
write on the file. Note that you’ll also need to block memory mappings,
since those you cannot do much about."
If I am correct, Tony suggested that we allow the open to proceed. But my
question is: If we allow the open to proceed, how exactly can we BLOCK
memory mappings in our FS filter/ minifilter?

Regards,
Ayush Gupta

9

My point was that you need to choose which horrible semantic case you
wish to implement - break applications that should work, or discard
write operations that you don’t wish to allow.

I have no insight into your goals here, but I must warn you that no
matter what you do, someone is not going to be happy with the results.

With respect to memory mapped files, if you allow a file to be opened
for write and then someone attempts to map it, you could fail it at that
point. That doesn’t break nearly so many applications as failing open
for write, but some programs will break.

Bill’s observation is a good one as well - there are likely other
techniques you would consider to be a “write” on the file that is not
done via IRP_MJ_WRITE. This would include rename, link, delete,
destructive create. Another interesting one would be the sparse API
(which allows me to put holes into files.) These are not write
operations, but you might consider them to be cases of interest.

I know people get frustrated sometimes when we ask “what are you trying
to accomplish” but the reason we ask it is because your question is
often mal-formed. It assumes things that are not true (e.g., “the only
way to zero out a file is to write on it.” That’s not true because I
could achieve the same thing with the sparse file API, for example.) If
you are writing a security product, no doubt you have a threat model
against which you are working - so tell us what it is and we might be
able to suggest things you had not ever considered.

Tony
OSR

10

Forward your create IRP it with the actual desired access, and then in post
create modify desired access to read only and object manager will create an
user mode handle with the post create desired access, if the operation
completed successfully.

I don’t know if this is a good way to accomplish this, but it might work for
you, but as everyone suggested applications might not like it.

With respect,
Gabriel Bercea

GaMiTech Software Development
Mobile contact: ?(+40)0740049634
eMail: xxxxx@gmail.com
Blog: http://gamitech.blogspot.com/
Linkedin: http://www.linkedin.com/in/gamitech
Twitter: http://www.twitter.com/gamitech

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, June 04, 2009 4:38 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Pretend a file as read-only

Hi,

Does anyone know how to “mask” a file with a assigned access right?

I know that the application will be able to collect the access right of a
file through IRP_MJ_CREATE. However, its access right can not be modified.
It makes it difficult to pretend a file as read-only through a mini-filter,
for example.

Introducing any idea will be highly appreciated.

Best regards,

NTFSD is sponsored by OSR

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

11

Hi,

Thanks for the suggestions from all of you.

I think it would be better for me to describe my intention, as there might be a better approach for the design goal.

What I have is a remote virtual volume, and I would like to let more than one users share the volume through the network. As the underlying protocol is disk access to the volume, there is no way to know which file is being accessed by each user. In order to keep file synchronization between users, I would like to let the first user who access a file get the write access, and the later users the read-only access only. So, neither the file content is to be keep read-only for the later user, the last access time or something like that are to be read-only. Only the first user is allowed to modify the file.

As folders maybe created by each user, the folders are also to be synchronized with the same design.

12

— On Fri, 6/5/09, Bercea Gabriel wrote:
> Forward your create IRP it with the
> actual desired access, and then in post
> create modify desired access to read only and object
> manager will create an
> user mode handle with the post create desired access, if
> the operation
> completed successfully.

Actually it is the other way around. If you forward the create IRP with the actual desired access and then in post create modify desired access to read only, the object manager will create a user mode handle with the pre-create desired access (regardless of the modifications you perform in post-create), if the operation completed successfully.

This topic has been discussed here before:

http://www.osronline.com/ShowThread.cfm?link=149502

Regards,
Razvan

13

>create modify desired access to read only

Modify where? in the IRP stack location?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

14

> and I would like to let more than one users share the volume through
the network. As the underlying protocol is disk >access to the volume,

I may have mis interpreted your design but my $0.02 is that these two
are mutually exclusive requirements. You should not share the FS like
this.

The scope of a project that has to satisfy both the requirements would
be much larger. Think some form of Clustered FS, distributed lock
management etc.

Harish
-----Original Message-----
From: xxxxx@gmail.com [mailto:xxxxx@gmail.com]
Sent: Thursday, June 04, 2009 7:54 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Pretend a file as read-only

Hi,

Thanks for the suggestions from all of you.

I think it would be better for me to describe my intention, as there
might be a better approach for the design goal.

What I have is a remote virtual volume, and I would like to let more
than one users share the volume through the network. As the underlying
protocol is disk access to the volume, there is no way to know which
file is being accessed by each user. In order to keep file
synchronization between users, I would like to let the first user who
access a file get the write access, and the later users the read-only
access only. So, neither the file content is to be keep read-only for
the later user, the last access time or something like that are to be
read-only. Only the first user is allowed to modify the file.

As folders maybe created by each user, the folders are also to be
synchronized with the same design.

NTFSD is sponsored by OSR

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

15

Yes.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Friday, June 05, 2009 11:57 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Pretend a file as read-only

create modify desired access to read only

Modify where? in the IRP stack location?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

NTFSD is sponsored by OSR

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

16

Hi Harish,

The Virtual Volume is like a physical drive that has no sense about the file system, and the minifilter I am trying to develop is about the file system and it has no sense about the underlying volume is virtual or physical. It sounds that there should be no mutually exclusive issue.

Best regards,

17

Does not work.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

“Bercea Gabriel” wrote in message news:xxxxx@ntfsd…
> Yes.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
> Sent: Friday, June 05, 2009 11:57 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Pretend a file as read-only
>
>>create modify desired access to read only
>
> Modify where? in the IRP stack location?
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

18

Yes I understand and I thought that you have to provide shared access to
this NTFS formatted virtual volume.
If so, you will run into situations where volume is getting updated from
more than one place. How do handle that ?

Harish

-----Original Message-----
From: xxxxx@gmail.com [mailto:xxxxx@gmail.com]
Sent: Sunday, June 07, 2009 8:53 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Pretend a file as read-only

Hi Harish,

The Virtual Volume is like a physical drive that has no sense about the
file system, and the minifilter I am trying to develop is about the file
system and it has no sense about the underlying volume is virtual or
physical. It sounds that there should be no mutually exclusive issue.

Best regards,

NTFSD is sponsored by OSR

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

19

Just to confirm Harish’s point…

This will not work with Microsoft filesystems (and probably most other
filesystems too.) It can work if all copies are mounted read-only,
since there is no synchronization issue between the copies. If one is
mounted writable, the writable guy can now have dirty cache data which
is not reflected on the read-only guy. After the write gets out, the
read only guy may still have a clean cache copy of the data, and has no
reason to refresh it. The result is amazing weirdness, ultimately
culminating in the filesystem detecting corruption, sending an event
log, marking the volume dirty, etc, etc.

If having a single writable copy is not a requirement, this can be made
to work. I would advise given the context that this could be approached
differently from the storage layer instead - filesystems query for
writability at mount time, and if the volume is write protected, the
filesystem takes care of all the hacks for you. Unfortunately (IIRC)
support for this in NTFS was added more recently (2003?), so it may not
be possible for you to use (but bear it in mind for future.)

If it is a requirement to have a writable copy, you are in for a world
of hurt. As Harish is pointing to, this now requires cross-machine
synchronization - you would be building a clustered filesystem to enable
the two to be coherent with one another.

  • M

Arora, Harish wrote:

Yes I understand and I thought that you have to provide shared access to
this NTFS formatted virtual volume.
If so, you will run into situations where volume is getting updated from
more than one place. How do handle that ?

Harish

-----Original Message-----
From: xxxxx@gmail.com [mailto:xxxxx@gmail.com]
Sent: Sunday, June 07, 2009 8:53 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Pretend a file as read-only

Hi Harish,

The Virtual Volume is like a physical drive that has no sense about the
file system, and the minifilter I am trying to develop is about the file
system and it has no sense about the underlying volume is virtual or
physical. It sounds that there should be no mutually exclusive issue.

Best regards,

NTFSD is sponsored by OSR

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

–
This posting is provided “AS IS” with no warranties, and confers no rights.

20

Malcom,

I disagree. We’ve made this work before, with single-writer,
multi-reader semantics on top of an NTFS file system shared across a
Fibre Channel. The “shadow file object” technique was, in fact,
something we invented (this is a long time ago) precisely to implement
this functionality (and since then we’ve used that same shadow file
object technique a number of times.)

As it turns out, we were stymied by a bug in NTFS at the time - it
caused an internal NTFS memory leak that would run the system out of
memory after 24 hours or so. But for that 24 hours, you had a shared
NTFS file system.

It was an interesting project.

Tony