I have been looking at the "System.Security.AccessControl" namespace in ".net 6" and can see how to get/set the Ntfs security on a file or folder. However, I am having trouble finding how to set it for a share on windows.
The documentation does suggest to me that it might be possible, because I see the "LMShare" type being listed here:
https://learn.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.resourcetype?view=net-6.0
However can't find what I would need to do.
Related
Currently we have a development cloud services (acme-dev-service) and a production cloud service (acme-prod-service). Our current setup in our solution has a cloud service project called acme.application that uses transformation of the .cscfg and .csdef files for deploying the project to the two environments (production and development). I don’t like the transformation method because it feels like a bit of a hack to me. So after doing some research it seems that you can have multiple configuration files which solves some of the issue but I am running into problems because you are only allowed one service definition. This doesn’t work for us because the production environment requires extra certificates as well as different hostHeader bindings than our dev environment does.
So it seems we cant really get away from using the transformations. So I guess my question boils down to am I looking at the Azure Service Project files in the wrong light? Should we really be mapping one Azure Project to one Azure cloud service? Should I have an Azure project for Production and a second Azure Project for Development?
Is there a better way to do this? Or a best practice for working with multiple environments in Azure?
The CSDefinition file is the real kicker here. If you have a value you need to be different between two environments (dev/test/stage/production, etc.) then you really have three options:
1) Manually modify the value before a deployment. Errr....Okay....you have two options.
1) Tap into the MS Build process and determine which cloud configuration you have selected (the one used to determine which version of the .cscfg file will be used) and then have the build modify the .csdef after the build and prior to packaging (there is a time when the file has been copied to a different directory just before packaging and this is where you want to make the change). This can be tricky, though I've seen it done and have even done so myself in the early SDK days. Here is a blog post explaining one example where he's using WebConfigTransformRunner to do just that: http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/. I don't really think this is your best option because it is opaque. It's not evident what is going on and someone who comes along after you to maintain the code will not know about this little gem and will spend forever trying to figure out why some value they put into the csdef somewhere is somehow getting overwritten after they publish to a different environment.
2) Use the two Azure Project approach you mentioned. You can set up build definitions in your Build tool of choice that determine which of the Azure projects you want to build and publish. Personally I think this is the best way to deal with different .csdef files. It's straight forward and doesn't require modifying the csproj files. I'm not opposed to csproj file changing, it's just not overly obvious it was done and, speaking as someone who has inherited things like that, it's not easy to find when people do that kind of thing and they aren't around to tell you about it.
Please refer to one of my previous questions. I'm asking about loading a compiled resource from a DLL. Then refer to the answer by David Heffernan. His suggestion is to use a built-in mechanism to load a resource directly from the DLL's instance, without even using my own exported function. This pointed out a security loophole to me.
If this is really the case, if this type of solution is possible, then can any outside third-party load resources from any Delphi Application/DLL? How secure are embedded resources? Suppose I compile a DLL with an embedded resource. Can someone take this DLL and extract the resource? How easy is it, considering they must know the resource name? Are they able to detect what resources are compiled and get a listing of named resources? If this is so, then I will have to implement my own level of security and encrypt every embedded resource and decrypt it with login.
The resource section of a Windows Portable Executable is accessible and enumerable to any process/user with read privileges over the executable file.
The Windows API provide a series of functions to work with resources, including functions to:
Adding, Deleting, and Replacing Resources
Enumerating Resources
Finding and Loading Resources
Resource File Formats
Using Resources
In fact there's plenty of ready tools to perform this operations. Your own Delphi installation have a demo project called Resource Explorer, usually installed in the folder Samples\Delphi\VCL\resXplor.
As you can see, anyone with the knowledge and/or tools can not only read, but delete and replace the resources found in your windows executable, regardless of the compiler that produced it.
You can find more information about the PE file format in the article An In-Depth Look into the Win32 Portable Executable File Format.
I created my custom assembly that has a simple HttpModule in it that I'd like to use in my Sharepojnt 2010 site.
I added my module to sharepoint site's web.config/system.webServer/modules section.
I then also copied my DLL directly to bin folder since that's how suual asp.net applications work. I got an exception about failed AspNetHostingPermission.
I copied the same DLL to _app_bin folder and it worked. My module did get initialized and was running.
I then added two permissions to my module class:
[AspNetHostingPermission(SecurityAction.InheritanceDemand, Level = AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission(SecurityAction.LinkDemand, Level = AspNetHostingPermissionLevel.Minimal)]
and also added these two to assembly
[assembly: SecurityPermission(SecurityAction.RequestMinimum, Execution = true)]
[assembly: AllowPartiallyTrustedCallers]
and strongly signed my assembly with a key I created.
Then I copied the DLL back to bin but it still didn't work. Copying it to _app_bin worked.
What do I have to do, to deploy my DLL directly to bin folder?
The problem you're running into is that SharePoint is using Code Access Security (CAS) to make it possible for really well educated Admins to make sure that they don't put their environment to unnecisary risk when adding functionallity to it.
The problem is then that even though CAS has been in .Net since the beginning nearly nobody has used it before SharePoint, so most developers don't know how to deal with it.
Everything in _app_bin is running with full trust, which explains why your dll works there.
Everything in bin is running with a lot less trust depending on the trust level specified in web.config (in fact this is also the one that specifies _app_bin has full trust, but thats common in all of the out of box trust levels).
In order to get your dll to work from bin (without changing trust level to full which is bad) you need to modify the policy file which the trust level is pointing to with the right xml for the right your dll need.
Adding the attributes don't help you directly, initially they in fact just makes the problem worse, because now your dll demands the rights even though it might not call anything which requires them.
Where the attributes help you is if you use WSPBuilder to build your WSP package for deploying to SharePoint (You're using a WSP right), then it'll look for security attributes and make the corresponding entries in manifest.xml which then get SharePoint to add the corresponding entries to the policy file on deployment.
In order for you attributes to work with WSPBuilder I think they have to be changed to SecurityAction.Demand though.
Since 2005, when Microsoft prevented HtmlHelp functioning off a network share, e.g.:
\\appserver\tos\PointScanner.exe
\\appserver\tos\PointScanner.chm
What are we supposed to do instead?
(Given that the application is not installed locally.)
To rephrase: What is Microsoft's intended, supported, out-of-the-box, help solution?
You can allow access via the Registry setting described here:
http://support.microsoft.com/kb/896054/
If you don't want to open any security vulnerabilities by modifying Registry settings your application could also create a local copy of the .chm file, e.g. in the users temp folder (%TMP%) and open the help from there. You can remove the file again when your application exits (in case you don't want to leave anything behind on the user's workstation)
I started with the registry change mentioned by divo. Eventually I moved from network folder based chm files to actual "html help". This was easy for me since I use RoboHelp which can generate either format from the same source code.
There are lots of similar questions to this, but they all seem to involve either configuring permissions or installing a plugin.
I'm looking for a solution that is "dumb" - i.e. to allow the code to be deployed from source control and automatically have access to certain paths blocked, without anyone needing to configure the server.
I only need directory & file blocking, none of the other abilities that .htaccess has.
Just to be clear, we are using ColdFusion, not .NET, and whilst CF has assorted ways to handle its own scripts, it doesn't do anything with non-CFML scripts. (It is possible to do, for example config.xml.cfm, but that is a messy solution that requires updating code, etc.)
(Of course, ideally these directories/files shouldn't even be in the webroot, and if I could switch to Apache or IIS7 I could simply use .htaccess, but those aren't options at the moment.)
My current solution is going to be a readme.deploy.txt that contains instructions on how to manually set the permissions on the relevant files & directories in IIS Manager, but obviously I'd much prefer to avoid human intervention for it - any suggestions?
You could create a script that would do this when you cycle through your deployment, like say a scheduled task where you use a PowerShell script or batch script that sets up the enviroment.
With IIS6 this is going to require mucking with the Metabase, which could solve your problem, but it will require scripts to have access to the system metabase and execute system commands or you going to have to learn how to use the ii6 metabase command files
see this This Article
If they have root access maybe it would be wise to just create a installation utility that can tweak the settings for them.
Good luck,
mike
Well, for ASP.net specifically you have the .config files which allow you to control some aspect of those web folders.
However, I'm not aware of anything like .htaccess for IIS.
.NET has Routing which allows you to 'rewrite' paths. The MVC framework has it built in... I'm not sure on how to configure/use it for 'normal' ASP.NET applications.
Update: didn't know you weren't on .NET.
Maybe you're just looking for File/Folder permission settings? Don't know anything about setting those by using a config file...