# Wednesday, April 12, 2006

I was recently asked by a very technical and very sharp friend of mine about the symantics of permissions on copy.

I figured if he needed some guidance on how this works then there must be a ton of other developers who could use a refresher so here goes:

There are alot of reasons that a developer or QA engineer must use copy or move to get their applications running for test or even for production.  The problem is that the same old processes that worked so many times before can often mask a misconception or two that arise as "bugs" when the moons do not align to make the old process function as expected.  Case in point.  You want to deploy a web application which has notoriously particular permissions requirements.  If copy has always worked in  the past, but on the new server you are getting strange permissions then you might be forgetting some of the rules.

The first thing to take into account is whether this is this a move within the same volume (nothing fancy) or a move across volumes (maybe obscured by DFS) or even just a plain old copy (often the case).

A move within volumes would mean you should have the permissions preserved. A move across volumes is actually a copy and a delete combined and means you are just getting the permissions of the target folder which is by design and this is also the behavior of a copy unless you use something like scopy which preserves permissions.

If a copy in the past has preserved permissions and you didn't use scopy (very handy by the way) then either there is a setting in Windows that I am unaware of (please enlighten me) or you got lucky in the past and the target folder permissions were what you expected.

Usually file permissions and especially the semantics of permissions on copy vs. move are the domain of network types.  In many cases it helps alot to be a mongrel from both worlds.

Wednesday, April 12, 2006 3:38:26 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0]  | 
# Wednesday, April 05, 2006

Like the Code Camps another good idea is coming out of the Microsoft Developer Evangelists.  This time it is a web site with an interesting concept.  If you go to http://www.community-credit.com/DevCommunity.aspx you will see it in action and also be able to see the people who are working hard to build their technical communities. Think of it as an ongoing public resume where people who contribute to the community get credit for their efforts.

I think this is a good step in building a nice feedback system so the dev community keeps going.

Check it out.

Wednesday, April 05, 2006 4:22:51 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [37]  | 
# Monday, March 27, 2006

As promised, but fashionably late as always, here are the slides from this Saturday's Mini Code Camp Security Edition.

I want to thank everyone that attended and the feedback has been great (no death treats so far)!

Membership.ppt (752 KB)
Security Best Practices.ppt (579 KB)

Check Duane's blog at www.cyberspacesamurai.com for his slides.

See you at the next Code Camp!


Monday, March 27, 2006 2:58:01 PM (Eastern Standard Time, UTC-05:00)  #    Comments [38]  | 
# Wednesday, March 22, 2006

In dealing with our teams of developers and engineers I find myself preaching some basic rules that make life easier for me when I try to deal with the legion of emails I get every day.  I thought to document them and in doing so realized that they have a decidedly security slant to them (big surprise).

Here are some rules of etiquette that will allow you to survive my spam filter (outlook junk mail) and not get deleted for cause:

  • Always put a subject on the message (the more specific the better).  I am noticing a ton of no subject emails in my junk mail folder and I don't scan the addresses before I delete them.  Not putting in a subject is a technique used by spammers to make you view the message.  For me and a growing number of people it backfires.  Call it a pet peeve, but if you can't be bothered to put a subject on a message then I can't be bothered to read it.
  • Never send an attachment unless I expect it (you told me in a previous message that you are sending it) or you explain what and why you are sending it in a way that lets me know that you had to have written it.  Remember that anyone can send a message as you if they really want to do it.
  • If you send me a link then tell me what is at the other end.  There are many sites that lure you in and do something amusing.  Why would you assume that they aren't being used to infect or subvert your computer.  There are many "drive-by" exploits that only need the page to be viewed from a vulnerable machine to do their work.
  • If I know a password or other secret then you can refer to the password or secret, but avoid sending it in an email.  It just isn't a secure medium.

I could go on and on about all caps being like yelling, but that isn't my intention.  I had figured that everyone already knew about these and yet I still get these things sent to me times per day and often by very technical people.

Be safe...

Wednesday, March 22, 2006 11:42:47 AM (Eastern Standard Time, UTC-05:00)  #    Comments [28]  | 
# Sunday, March 05, 2006
Ted Neward just launched his new site at http://www.tedneward.com.  Check it out, Ted is one of the most interesting and intelligent people I know.  If you ever need to cross the .Net platform with Java then he is the guy to take a lesson from.
Sunday, March 05, 2006 5:44:07 PM (Eastern Standard Time, UTC-05:00)  #    Comments [22]  | 
# Tuesday, February 28, 2006
Microsoft has chimed in on the questions about ClickOnce security raised by Dominick Baier and basically is asserting that this is a non-issue.

I am not buying.  I think that using the excuse that older technologies do something a certain way undermines the principle of secure by default.

What do you think?
Tuesday, February 28, 2006 9:10:41 PM (Eastern Standard Time, UTC-05:00)  #    Comments [32]  | 
# Monday, February 27, 2006
If you are at all into security or even if you just think technology is cool then you have to watch the latest episode of the The Code Room.  In this latest episode you will see our own Duane Laflotte, our resident top security expert as part of the team of evil doers that hack a casino in vegas.

I think it is really well done and makes some good fundamental points about security in a very entertaining way.
Monday, February 27, 2006 2:24:29 PM (Eastern Standard Time, UTC-05:00)  #    Comments [2]  | 
# Friday, February 24, 2006

When I was in Cairo for the MDC a few weeks ago, I gave several talks that touched on the new membership controls in ASP.Net 2.0.  One question that came up repeatedly was how far can you stretch the provider before you have to write a custom membership provider.  The answer turns out to be not very far.  The provided membership providers are very good and very extensive, but they are also fairly rigid in their implementations. 

I think I have the 3 criteria that will force you to realize that you need to bite the bullet and write your own membership provider:

  1. If you need to access your own schema that is different (in any way) from the schema provided.  Running Aspnet_regsql.exe creates a database and if you need to edit that schema then you cannot live without a custom provider except if you are adding tables for your own use, but bear in mind that the provider will just ignore your additions.
  2. If you need to access data in someplace that is not supported.  Even if you want the same schema as the default providers support, you cannot use a proprietary database for that data and expect the providers to just work.  The XML provider is the most common example (though not very real world), but you could think of many scenarios including SQL 7.0 where a custom provider would be in order
  3. If you need / want to insert some abstraction between the provider and the data.  Stefan Schackow of Microsoft had a great session at PDC 2005 in which he demonstrated creating a provider that allowed for the situation where your web servers were not in direct contact with the database server.  To solve that problem he wrote a provider that took a web service endpoint as its connection string.

So as you can see you are quite likely to find yourself having to write your own provider.  The good news is that it really isn't that hard to do once you have done it once or twice ;)

Friday, February 24, 2006 11:02:41 AM (Eastern Standard Time, UTC-05:00)  #    Comments [24]  | 
# Monday, February 20, 2006
Dominick Baier of DevelopMentor, wrote on Saturday about a pretty dramatic change in the way ClickOnce security is configured by default in the RTM version of .Net 2.0. 

This is a must read if you plan to use ClickOnce and haven't already revamped the default security settings.  If you don't like the ramifications that not being able to disable ClickOnce brings then rather than avoiding the .Net 2.0 offering you might consider the lesser step of just removing the .application mapping from your systems.

I am hopeful that Microsoft will come up with a fix in a service pack to .Net 2.0 as they did in the original .Net 1.1 that will address this default.
Monday, February 20, 2006 11:22:36 PM (Eastern Standard Time, UTC-05:00)  #    Comments [22]  | 
# Wednesday, February 15, 2006

A recent court case was brought to my attention in which a user whose personal and financial information was stolen tried to sue the company for not using encryption on the data.  The article covering it is explains how the data was stolen and the ruling of the courts.

The question raised is whether the suit should have been supported?  While I agree with the ruling, I think that certain industries need to actually gradually design best practices like the use of encryption into their required security precautions.  This may be pandora's box, but if it is done over time then it might actually be done right (wishful thinking?).

Security is still black art to most people.  We need to define "reasonable measures" in ways that make sense to the masses.

Wednesday, February 15, 2006 9:29:49 PM (Eastern Standard Time, UTC-05:00)  #    Comments [22]  | 
Site Search


Locations of visitors to this page