Michael,
Basically, if you left the API public, as is, it allows anyone to pass
a file
handle to any file. This is considered insecure. If you exposed another
public method which took a SafeHandle which represented a file and then acted
as a passthrough to the API method, then this would be insecure as well, and
it's at that point that you should basically create a new SecurityPermission
and call the Demand method on it yourself, something like:
[DllImport, SuppressUnmanagedCodeSecurity]
private static ...
public void FlushFileHandle(SafeHandle handle)
{
// Other code.
// Demand permission.
new SecurityPermission(SecurityPermissionFlag.UnmanagedCode).Demand();
// API Call.
...
}
However, because you are managing the file handle yourself, and not
exposing
a method to arbitrarily make calls to the API through other public members,
then making the demand is unnecessary:
public void ManipulateFile()
{
// Do some stuff.
// Call the API. Note the handle is for a file that the instance
manages,
and is expected, and
// doesn't allow for calls arbitrarily to the API.
...
}
- Nick
-----Original Message-----
From: Michael Garski [mailto:mgar...@myspace-inc.com]
Sent: Monday, November 09, 2009 9:16 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Nick -
Great feedback, thanks!
I'll mark it private & add the SuppressUnmanagedCodeSecurity attribute.
I don't quite follow the point of "... going to expose a public method which
accesses the API in some manner which is able to be compromised, you need to
demand the unmanaged code permission in the public method before calling the
API."
Could you elaborate on that?
Thanks,
Michael
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casper...@caspershouse.com]
Sent: Monday, November 09, 2009 5:52 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Michael,
The P/Invoke declaration of the FlushFileBuffers API method should be
marked
as private. You really don't want this hanging off the type publically.
Also, in addition to making it private, you should apply the
SuppressUnmanagedCodeSecurity attribute to it to prevent security stack walks
every time that this method is called (the permission stack walk will still
occur at link time though).
This is especially important when you have partially trusted
callers/restricted environments (shared hosting is a good example), because
unmanaged code might not be able to be called outright without this attribute
being applied.
If you ^do^ apply the attribute, then you really ^must^ make the method
private, and if you are going to expose a public method which accesses the API
in some manner which is able to be compromised, you need to demand the
unmanaged code permission in the public method before calling the API.
- Nick
-----Original Message-----
From: Michael Garski (JIRA) [mailto:j...@apache.org]
Sent: Monday, November 09, 2009 6:56 PM
To: lucene-net-dev@incubator.apache.org
Subject: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush
to Disk
FSDirectory.Sync Fix to Ensure Flush to Disk
--------------------------------------------
Key: LUCENENET-216
URL: https://issues.apache.org/jira/browse/LUCENENET-216
Project: Lucene.Net
Issue Type: Bug
Reporter: Michael Garski
DIGY and Doug discussed this issue during the 2.9 port, and this is a patch to
give 2.9 the expected behavior of actually ensuring the OS flushes it's
buffers to disk. DIGY suggested using the kernel32 method FlushFileBuffers,
and after investigation he was correct! FileStream.Flush doesn't do that -
the OS could still be caching it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
smime.p7s
Description: S/MIME cryptographic signature
