Day 1 of DevDays 2004 is over.

First of all, one of the questions I see coming back here: Which Whidbey version do you get?

Well, here is what we got:

• Visual Studio Whidbey Prerequisites Build 30703.27
  


• Visual Studio Whidbey Enterprise Architect Edition Build 30703.27 4CD
  


• MSDN Library for Visual Studio Whidbey Build 3231 3CD

Now, I don't know of those are the PDC bits or not, I guess they are. (Update: as Jason Nadal posted in the comments, these are the PDC bits)

I'm going to make some separate posts about separate sections.

What I'm not going to do, is tell the stuff that was on their slides. I guess they'll become available soon anyway, so you can read it. Instead I'm going to make remarks on the sessions, things that for me personally caught my attention.

Let's start the journey I guess:

Today I needed to set NTFS permissions in C# on some newly created directories.

No problem I thought, the CLR will have something for it somewhere in Security, so I checked Google in the hopes to find which class to use.

But Google didn't find anything... This amazed me. "Why can't I control NTFS permissions with .NET ?!?"

After looking for an hour or so, I found a GotDotNet User Sample, called 'ACLs in .NET'. Finally I thought, now it's going to be plug in and set rights.

Well this library is great. It makes settings NTFS rights so easy.

But it lacks a bit in documentation. Therefore I'm providing some of the code I used with it, it could help you. (or it could show my possibly bad coding style, as far as my knowledge goes for know, it should be fine)

Reference the dll, and use it.

[csharp]using Microsoft.Win32.Security;[/csharp]

Here's a method to add a dir, and set NTFS permissions on it for a given user:

[csharp]
private Boolean CreateDir(String strSitePath, String strUserName) {
Boolean bOk;

try {
Directory.CreateDirectory(strSitePath);
SecurityDescriptor secDesc = SecurityDescriptor.GetFileSecurity(strSitePath, SECURITY_INFORMATION.DACL_SECURITY_INFORMATION);
Dacl dacl = secDesc.Dacl;
Sid sidUser = new Sid (strUserName);

// allow: folder, subfolder and files
// modify
dacl.AddAce (new AceAccessAllowed (sidUser, AccessType.GENERIC_WRITE | AccessType.GENERIC_READ | AccessType.DELETE | AccessType.GENERIC_EXECUTE , AceFlags.OBJECT_INHERIT_ACE | AceFlags.CONTAINER_INHERIT_ACE));

// deny: this folder
// write attribs
// write extended attribs
// delete
// change permissions
// take ownership
DirectoryAccessType DAType = DirectoryAccessType.FILE_WRITE_ATTRIBUTES | DirectoryAccessType.FILE_WRITE_EA | DirectoryAccessType.DELETE | DirectoryAccessType.WRITE_OWNER | DirectoryAccessType.WRITE_DAC;
AccessType AType = (AccessType)DAType;
dacl.AddAce (new AceAccessDenied (sidUser, AType));

secDesc.SetDacl(dacl);
secDesc.SetFileSecurity(strSitePath, SECURITY_INFORMATION.DACL_SECURITY_INFORMATION);
bOk = true;
} catch {
bOk = false;
}

return bOk;

} /* CreateDir */
[/csharp]

The AceFlags determine the level of inheritance on the object.

And the DirectoryAccessType is used to create a AccessType with some permissions not in the AccessType enum.

I hope this is useful.

Here's a dilemma:

On one side you want to keep your machine up to date with all latest patches, but then there is "Cumulative Security Update for Internet Explorer (832894)", which disables the user:pass@ way of authentication.

Now, do you update and loose this functionality (which can be handy), or don't apply it but have the other security it fixes unpatched?

Here's what I did:

I patched!

…

But I really, really wanted the user:pass back, and it's even in an RFC MS has linked.



The solution? Re-enable it!

Start regedit.

Go to:
HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
to re-enable it for the entire machine,

or go to:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
to re-enable it for the logged in user.

Now create iexplore.exe and explorer.exe DWORD values and set their value data to 0.

Done, you just got the user:pass@ functionality back.


Update:

As Kent Sharkey writes, the RFC I quoted actually did not specifiy the user:pass possibilty for the HTTP protocol. I'm sorry for that, it's a 'feature' I guess :)

This registry tweak does however not undo the patch, it only reactivates this 'feature', the chr(0) exploit remains fixed with this tweak.

Update2:

Here is a .reg file to re-enable it system-wide.