I implemented a feature that allow users to upload files. Everything was working perfectly on my machine. After we deploy it, I got the following error:
Access to the path '\...\VendorDocuments\TempFolder\2585' is denied.
I've added EveryOne in the list of the object that have all the permissions to the VendorDocument folder. It worked.
Now I'd like to know how to setup the permissions to take into account the security aspects.
vendorDocuments is the main folder.
Inside vendorDocuments there is another folder called TempFolder
When user selects a file, the file is automatically uploaded to a TempFolder/UserId
If the user decides to cancel the operation, the file inside the TempFolder is deleted.
If the user decides to proceed, the file will be moved from the TempFolder/UserId to a folder belonging to the vendor still inside vendorDocuments.
VendorDocuments => TempFolder => TempFolder => UserId (file inside)
VendorDocuments => VendorName => DocumentId (file inside)
So in my opinion, there are 2 problems;
How to setup the permission on the highest level, i.e. vendorDocuments folder.
Do I need to setup permission as well for every vendor folder, i.e. where files belonging to a given vendor will be saved. There reason I asking this question is because I read that it's better to setup manually permission on folder. However, in this case, vendor's own folder will be created on the fly, i.e. the first time a user belonging to that vendor upload a file.
Sorry to ask a long question. This is the first time I'm working with permissions.
We take care of our permission like this by assigning an application pool identity to the application itself. This allows you to give the applications account the permissions it needs to write files to their destination. We are using IIS and I can see that depending on your version of IIS the process is slightly different. IIS instructions: http://www.iis.net/learn/manage/configuring-security/application-pool-identities
Related
Noticed this when creating a new directory in unix, and was just curious as to why this is so.
Thanks
A new directory created by a user and owned by the user with full permissions is no big deal. However, a new file/program if executed accidentally or before configuration could have catastrophic results. So the designers decided to give you a layer of protection.
It also prevents other users from executing the file unless you specifically grant permission.
Because you need the executable permissions to naviguate into the directory.
So basic permissions allow user to read file (read file permission), and to access file in directory (directory execute permission).
Note that read permission on a folder allow user to list files in it. (But doesnt allow to read them unless execute permission is granted too as I said in the first place)
Basically, +x on a directory means that the user can 'execute it' hence change into it (replace user by group or other depending on position in permissions).
Hence drwxr--r-- means only user can change into directory. More here.
The directory needs to have executable permissions so you can do things such as cd into it. Also the executable permission lets you look into the directory for inode information of the files it contains.
More info can be found at this source.
I am using WebDav to copy and paste multiple files into Alfresco.
The problem is that I can only do this with administrator IDs.
When I try to create new files or update existing files as a non-administrator
user, I get the following error:
HTTP Status Code: 403 caused by: org.alfresco.repo.security.permissions.AccessDeniedException: 03300303 Access Denied. You do not have the appropriate permissions to perform this operation.
Is there anyway to allow non-administrator IDs to create/update files?
The Alfresco WebDAV support uses identical permissions to the rest of Alfresco. Nothing special - it's just one of the number of different ways you can interact with the nodes stored in your Alfresco repo.
As such, the user you log in as needs to have both read and write permissions to the folder in question. Typically, that means they need to be a member of the site you want to write to, and need to have permissions higher than Consumer.
As long as the user has write permissions to where you want to write to, they'll be able to make changes using WebDAV.
I've developed an ASP.NET v4 web app which I am trying to get to write to a folder in the webroot.
For the life of me I cannot get Windows 7 to allow it to write a file, I get Access is Denied error each time.
What I have tried on the folder is
attrib -r /foldernameandpath
attrib -r -s /foldernameandpath
Removing Check from ReadOnly attribute in folder properties
Changed owner to folder to current user whom is also the admin
Changed owner to Everyone
Adding Everyone user to folder with all permissions
Changing the folder to the Public Document directory
Changing to the root of the C drive (Out of desperation)
Nothing seems to work and all I want to do is test that the write works.
Now I know the system works and writes fine cause I had this same web app on a second machine writing the PDFs to the C drive without issue. This second machine I just cannot get it to allow the write.
Oh please for the love of all things holy, put the keyboard and mouse down and stop what you are doing. Some of the actions in your list seriously frightens me.
All the things you list as your actions are most likely useless or desperately random at best.
As a web developer, you shouldn't have to start messing around changing ownership of folders, especially not the web root folder normally used by the web server. When you do, you'll end up in a dark, cold and lonely place. Lord only knows what other desperate measures you have taken. For your own sake, I'll recommend you to do a system restore or even system reinstall to make sure you are in a healthy state.
Let's go back one step and try to sort out what you are doing.
First: what is the path you are trying to write to?
Second: are you running this application directly from within Visual Studio or in IIs?
If you are doing the first option then your current user account is the account who tries to write to the path in question. Do you have write permissions there?
One thing you can try is to start Visual Studio with elevated permissions and see if that works.
If you are running in IIs, it the associated pool account that needs write permissions.
Are you doing impersonation by any chance? If so, make sure the impersonated account have proper permissions.
You should only write to a predefined folder within your app path, like ..\App_Data for example.
The easiest way to find out which account you are running with and determine what path you are trying to write to, is to fire up SysIntenals process monitor and find the entry with the access denied result. Select properties for that entry and find out which account tried to do the write action. When you have determined that, right click on the folder in question and give the proper account write permissions.
I recently switched my development machine from Windows XP to Windows 7 and since that switch, I have a problem with files permissions when I do operations with Tortoise SVN.
Example:
I Have two ASP.NET website set on my local IIS. Beta and Devlo. Beta is a check out of the branch I'm working on and Devlo is a check out of the Trunk.
I made some change on the Beta website and Check it in.
Then I made a merge to reintegrate the branch in the truck on the Devlo website, but I got this error when I test it :
Parser Error
Description: An error occurred during the parsing of a resource required to
service this request. Please review the following specific parse error details
and modify your source file appropriately.
Parser Error Message: Access to the path 'C:\[...]' is denied.
After investigation, I discovered that every file that was modified by the Tortoise SVN merge lost theirs file permission (Read, Read & Execute) for the users IUSE and IIS_IUSRS.
I could manually put them back, but this happen every time I perform an operation of this kind. Is there a way to keep those permissions unchanged by the SVN operation?
Update
Before the Merge, the file was inheriting is permission from the parent folder (has it's supposed to do.)
But not after the merge :
The original file (in the beta folder) was inheriting is permission from the parent folder.
Why the TortoiseSVN (explicitly?) block permission inheritance?
I had the same issue and fixed it with the help of this SO answer: https://stackoverflow.com/a/8993163/361831
The answer mentions that updated files are copied to a .svn/tmp directory which is located in the top level of your working copy (as of tortoiseSVN 1.7). This top level dir didn't have the IIS permissions so I guess they weren't inheriting during the copy. So I just set the IIS permissions to that top level dir and set to inherit, and that fixed the issue.
When subversion updates a file it first creates a temporary version in .svn/tmp/. It then moves the file into the right location. (This to avoid corruptions)
In 1.6 it did this for every directory by itself, but in 1.7 there is just a .svn in the top level directory of your working copy.
If somehow the filesystem permissions of this .svn directory are restricted, it is possible that the restrictions are copied with the file when it is moved in place. (Subversion doesn't change the permissions itself on Windows)
ANSWER: Locate your .svn directory for that project and fix the permissions with permissions needed by your project.
You should be able to set these permissions on the folder that contains the files and then let the files inherit these permissions, instead of explicitly setting the permissions on the files themselves.
TortoiseSVN may delete and create files instead of renaming. When a new file is created this way it will not have the original permissions, but it will inherit permissions from its container.
See also: Explicit vs. Inherited Permissions
Each permission that exists can be assigned one of two ways:
explicitly or by inheritance. For this reason, permissions are
referred to as explicit permissions and inherited permissions.
Explicit permissions are permissions that are set by default when the object is created, or by user action.
Inherited permissions are permissions that are given to an object because it is a child of a parent object.
Similar to the way rights are managed for groups of users, permissions
are best managed for containers of objects. Objects within the
container inherit all the access permissions in that container.
See also: TortoiseSVN - Deleting, Moving and Renaming
Since renames and moves are done as a delete followed by an add...
I had the same problem on both my Win7 64bit machines. I would check in code on one, go to the other, do a Tortoise SVN Update, and have to reset the permissions on the folder to let the parent folder's permissions propagate downwards.
I finally found this article, tried it, and two weeks later it seems to be holding up.
Open the Registry Editor (click Start > Run, type regedit, then press ENTER).
Locate the following registry key:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
With the key selected, on the Edit menu, click Add Value, and then add the following registry value:
Value name: ForceCopyAclwithFile
Data type: DWORD
Value data: 1
Exit the Registry Editor.
http://kb.globalscape.com/KnowledgebaseArticle10473.aspx
I have a ASP.NET application that we've written our own logging module for.
My question is, where is the standard place to write a log file to? I.e. the website will be running as the anonymous user identity (e.g. IUSR on IIS7) and I need a place where I know it'll have permission to write to.
Cheers,
App_Data folder on the root of the project. It isn't served to web requests; so other people can't snoop for it.
I would suggest putting the log file onto a seperate disk, though should give you a little performance gain so that your not trying to both read and write to the same disk as the website. If you cannot put the log file on a seperate disk, then I would simply choose a folder of your choice.
In any case, you will have to give the "Network Service" account "Modify" permissions to the desired folder.
If on the other hand, you have access to a databse, then log the information there. It will be much quicker than accessing the hard drive and won't be publically available. You'll also be able to report from the data quite easily.
I'm not in a position to modify the permissions on folders (especially outside of the virtual directory home folder), and don't already have an App_Data folder, so am a bit hesitant to go with that.
So for the moment I'm going with the CommonApplicationData Folder.
On Vista/Server 2008 this is C:\ProgramData\
On XP/Server 2003 this is C:\Documents and Settings\All Users\Application Data\
I'm not in a position to modify the permissions on folders (especially outside of the virtual directory home folder), and don't already have an App_Data folder, so am a bit hesitant to go with that.
If you have a website, you clearly have a folder somewhere. Can you not add a (non-web-facing) subfolder? It seems like that would be a more appropriate place to put your logs than dumping them into a global, shared folder.
You could also log to the Windows Event log or to a table in a database. How often are people looking at the event log? If it's being examined on a regualr basis, writing to a table amkes the reporting back much easier as it's trivial to reverse the order and only show the last X events for the current time period. The Windows Event log you can also query the Windows Event Log through PowerShell or with LogParser.
Push the app_data is the best idea, just bear in mind, when the publishing the projects, if the option "Delete all existing files before publishing" is ticked, then the current data in the folder will be gone. The workaround is to skip the deletion of app_data folder.
Another option to do logging is to use some existing framework such as Log4net.