lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Garski <mgar...@myspace-inc.com>
Subject RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Date Tue, 10 Nov 2009 03:05:08 GMT
Gotcha - thanks for the info!

Michael

-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com] 
Sent: Monday, November 09, 2009 7:03 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk

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:mgarski@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:casperOne@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:jira@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.
Mime
View raw message