I've seen a lot of answers on copying files that use code to set a network share, with credentials, to copy to somewhere else. However I need a solution that will allow a user to copy from a network share they already have access for, to a local drive they don't have access to.
We run RDS servers and have locked down direct access to the local C:/ drive on the servers. We have been given a 3rd party program that needs to read data files that must be stored in a fixed path on the C:/ drive. These data files are updated once a month. Our users have read access but we do not want to give them direct write access to the root C:/ drive.
I need to write a piece of vb.net, or command line code in .bat file that will copy files to the Local C:/ whilst providing the details of a service account to provide the access.
As mentioned I've seen a lot about setting up a mapping to shared folder and passing creds, however we don't want to set the C:/ as mapped shared drive in this instance.
You don't want the user having access to the C Drive in general, is there any particular reason the permissions on the particular subfolder the files are going to can't have overriding permissions to allow writing to just that folder?
If that will not work, first thought that comes to mind is having a helper program that can be ran under a different user that does have that access. Set up an intermediate folder the user can write to, the program that they can launch drops the files into a folder they have access to. Helper program watches for files in the intermediate folder, moves them to where they need to be.
Set up would need to include adding a user that does have access to both locations, and then adding to task manager to launch the helper program under that other user at login.
Is there some easy way to permanently allow myself full access to all folders and files? I am the only user on a freshly formatted PC, and every answer I could find online seemed to be per folder and a one time solution.
An example of not being able to open a folder is the WindowsApps Folder in my D: Drive.
C:\Program Files\WindowsApps is a restricted folder used for the Windows Store apps. It's designed that way as a security feature to limit the access windows store apps have to your Windows OS. Not all apps on the Windows store are audited and checked to confirm their legitimacy. The folder is purposely designed to act as a little island separated from your user profile and sensitive data. You can gain ownership of it though...
You already found it by enabling show hidden items, so you can go to the folders properties > security > Advanced > Change > [enter your username] > check the box to 'Replace owner on subcontainers and objects' on the next screen. You should now have access to that folder.
As soon as I take away EVERYONE from the root folder (Company Home) in alfresco, some custom webscripts stop working and respond that this folder cannot be found. I would like to give a subset of EVERYONE (eg GROUP_A) permission from the rootfolder down. The "normal" usage of alfresco through Share keeps working when I do just that, only the webscripts give me some trouble. There are answers like this one:
Alfresco openCMIS connect to home folder
But that's just a workaround. Maybe some kind of system user needs to have permissions on the root folder?
I think this is a similar question: Alfresco webscript can't find Company Home folder
The most clear answer is (depends on which version you are) that the webscripts, CMIS & Java code need to know the path of the node you are in.
In Previous Alfresco versions even in Share a user needs to have Consumer rights on the parent folder otherwise the breadcrum would fail to load and other issues.
In 4.2.x if you retrieve a document/folder and you as user don't have rights on one of the parents folders OpenCMIS code breaks. This will/should also happen on some webscripts.
A user needs rights on the template folders within Data Dictionary, so it's good to keep the EVERYONE group on Data Dictionary.
Where would you write an error log file, say ErrorLog.txt, in Windows? Keep in mind the path would need to be open to basic users for file write permissions.
I know the eventlog is a possible location for writing errors, but does it work for "user" level permissions?
EDIT: I am targeting Windows 2003, but I was posing the question in such a way as to have a "General Guideline" for where to write error logs.
As for the EventLog, I have had issues before in an ASP.NET application where I wanted to log to the Windows event log, but I had security issues causing me heartache. (I do not recall the issues I had, but remember having them.)
Have you considered logging the event viewer instead? If you want to write your own log, I suggest the users local app setting directory. Make a product directory under there. It's different on different version of Windows.
On Vista, you cannot put files like this under c:\program files. You will run into a lot of problems with it.
In .NET, you can find out this folder with this:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
And the Event Log is fairly simple to use too:
http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx
Text files are great for a server application (you did say Windows 2003). You should have a separate log file for each server application, the location is really a matter of convention to agree with administrators. E.g. for ASP.NET apps I've often seen them placed on a separate disk from the application under a folder structure that mimics the virtual directory structure.
For client apps, one disadvantage of text files is that a user may start multiple copies of your application (unless you've taken specific steps to prevent this). So you have the problem of contention if multiple instances attempt to write to the same log file. For this reason I would always prefer the Windows Event Log for client apps. One caveat is that you need to be an administrator to create an event log - this can be done e.g. by the setup package.
If you do use a file, I'd suggest using the folder Environment.SpecialFolder.LocalApplicationData rather than SpecialFolder.ApplicationData as suggested by others. LocalApplicationData is on the local disk: you don't want network problems to stop you from logging when the user has a roaming profile. For a WinForms application, use Application.LocalUserAppDataPath.
In either case, I would use a configuration file to decide where to log, so that you can easily change it. E.g. if you use Log4Net or a similar framework, you can easily configure whether to log to a text file, event log, both or elsewhere (e.g. a database) without changing your app.
The standard location(s) are:
C:\Documents and Settings\All Users\Application Data\MyApp
or
C:\Documents and Settings\%Username%\Application Data\MyApp
(aka %UserProfile%\Application Data\MyApp) which would match your user level permission requirement. It also separates logs created by different users.
Using .NET runtime, these can be built as:
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
or
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
followed by:
MyAppDir = IO.Path.Combine(AppDir,'MyApp')
(Which, hopefully, maps Vista profiles too).
Personally, I would suggest using the Windows event log, it's great. If you can't, then write the file to the ApplicationData directory or the ProgramData (Application Data for all users on Windows XP) directory.
The Windows event log is definitely the way to go for logging of errors. You're not limited to the "Application" log as it's possible to create a new log target (e.g. "My Application"). That may need to be done as part of setup as I'm not sure if it requires administrative privileges or not. There's a Microsoft example in C# at http://support.microsoft.com/kb/307024.
Windows 2008 also has Event Log Forwarding which can be quite handy with server applications.
I agree with Lou on this, but I prefer to set this up in a configuration file like Joe said. You can use
file value="${APPDATA}/Test/log-file.txt"
("Test" could be whatever you want, or removed entirely) in the configuration file, which causes the log file to be written to "/Documents and Settings/LoginUser/Application
Data/Test" on Windows XP and to "/Users/LoginUser/AppData/Roaming/Test on Windows Vista.
I am just adding this as I just spent way too much time figuring how to make this work on Windows Vista...
This works as-is with Windows applications. To use logging in web applications, I found Phil Haack's blog entry on this to be a great resource:
http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx
%TEMP% is always a good location for logs I find.
Going against the grain here - it depends on what you need to do. Sometimes you need to manipulate the results, so log.txt is the way to go. It's simple, mutable, and easy to search.
Take an example from Joel. Fogbugz will send a log / dump of error messages via http to their server. You could do the same and not have to worry about the user's access rights on their drive.
I personally don't like to use the Windows Event Log where I am right now because we do not have access to the production servers, so that would mean that we would need to request access every time we wanted to look at the errors. It is not a speedy process unfortunately, so your troubleshooting is completely haulted by waiting for someone else. I also don't like that they kind of get lost within the ones from other applications. Sure you can sort, but it's just a bit of a nucance scrolling down. What you use will end up being a combination of personal preference coupled along with limitations of the enviroment you are working in. (log file, event log, or database)
Put it in the directory of the application. The users will need access to the folder to run and execute the application, and you can check write access on application startup.
The event log is a pain to use for troubleshooting, but you should still post significant errors there.
EDIT - You should look into the MS Application Blocks for logging if you are using .NET. They really make life easy.
Jeez Karma-killers. Next time I won't even offer a suggestion when the poster puts up an incomplete post.
When an ASP.NET application is running under IIS6.0 in Windows 2003 Server with impersonation, what user account is relevant for deciding file read/write/execute access privileges? I have two scenarios where I am trying to understand what access to grant/revoke. I thought the most relevant user is probably the identity specified in the Application Pool, but that doesn't seem to be the whole story.
The first issue concerns executing a local batch file via System.Diagnostics.Process.Start()--I can't do so when the AppPool is set to IWAM_WIN2K3WEB user, but it works fine if it is set to the Network Service identity. I of course made sure that the IWAM user has execute rights on the file.
The second involves writing to a file on the local hard drive--I'd like to be able to prevent doing so via the access control list via folder properties, but even when I set up all users in the folder as "read" (no users/groups with "write" at all), our ASP.NET still writes out the file no problem. How can it if it doesn't have write access?
Google search turns up bits and pieces but never the whole story.
what user account is relevant for [..] file read/write/execute access
As a rule: Always the user account the application/page runs under.
The IWAM account is pretty limited. I don't think it has permissions to start an external process. File access rights are irrelevant at this point.
If a user account (Network Service in your case) owns a file (i.e. has created it), it can do anything to this file, even if not explicitly allowed. Check who owns your file.
Process Monitor from Microsoft is a great tool to track down subtleties like this one.
A bit more searching reveals that the IWAM user isn't that well documented and we should stick with NETWORK SERVICE or a manually-supplied identity if we want to specify permissions for that user.