I'm not great with windows server so not sure of the best way to describe this. I have a Windows 2003 Server box running IIS 6. I'm giving a designer FTP to a specific folder on the root and allowing read/write access. This is so they can't touch the rest of the website.
However, his scripts surely would be able to? For example he could create an upload script? What's the best way to "self-contain" this folder?
Cheers,
RJ
What i would do if possible is to remove the execute rights for that folder in IIS
In IIS MMC expand the website, select the folder and open the properties windows.
On the Home Directory tab, Change the execute permissions to **NONE**
This would allow them to upload files (any files) but scripts in that folder will not execute/run
Hope this helps.
Related
I have a directory on my server, Ubuntu Linux, and it contains a bunch .csv files and is updated regularly, I need to be able to sync that folder with a folder on a local machine which is a Windows PC.
There's no problem connecting via FTP, filezilla, but it's the automation I need to work out out.
The files once downloaded are then screened for deliveries.
I can't seem to see anything of help online.
In Windows you can use WinSCP instead of Filezilla, it have a option "Autosync" every time a specific files change on local computer.
You can download and read the documentation in the oficial website:
https://winscp.net/eng/download.php
I am working in a mixed environment of Mac OS and Windows machines, which the domain controller is Open Directory served by a Mac server. Actually, Mac and Windows both are installed on every machine and could be selected on boot time.
As a longtime problem, we could not join Windows 7 users to Open Directory domain. That's why I decided to setup an Active Directory server for Windows users and leave Open Directory for Mac users. Then the next problem was we must have each user twice in both Open Directory and Active Directory.
My question is: Is there a way to configure AD to relay its authentication requests to OD user database, and also load home directories from a shared point on the network?
An Open Directory can be used as PDC or a BDC and yes you can replicate active directory into your Open Directory server. once that is said, setting up a new Open Directory BDC is not a question of two lines of code. I'll suggest you to read the following:
http://manuals.info.apple.com/MANUALS/1000/MA1180/en_US/OpenDirAdmin_v10.6.pdf
you may find more than you are looking for. :)
I have a setup project that installs my app to the typical program files directly.
My app periodically saves some temporary images to the apps installation folder. It seems on Vista, the permissions are not setup for write permissions. I can change it manually in windows explorer and it works, but I would rather have the setup project do that automatically.
How can I do this?
Is there a better/more normal place to put temp images that won't have permissions issues?
It is not Vista specific, this will happen with any kind of user account that doesn't have admin privileges. Your program just can't write to folders like c:\program files\blah. That UAC disables admin privileges has been publicized for a long time now. Use Environment.GetFolderPath() to get the path to an ApplicationData folder that you can write to.
See http://msdn.microsoft.com/en-us/library/bb756940.aspx for details on UAC issues for vista. These problems can also occur in other versions of windows when running applications from non-admin accounts. You should only write data to app data or temp directories and not program files.
I have an app modified to take into account the UAC in VISTA.
So, now, the .mdb (JET or Access file) is located in ProgramData\MyApp\
I realized that when my app reads the database for the first time it is doing it from that location... but when my app is writting to the database... the file is virtualized and goes to Users\MyUser\AppData\Local\VirtualStore\ProgramData\MyApp. From this moment on my app always go to the Virtualized location in disk.
My app is working, but if I continue this way, the database would be in a per-user basis, and we really need sharing the database with all the users in the PC.
I thought that writting under ProgramData folder would't trigger the virtualization mechanism.
What I'm missing?
I need to set the permissions for MyApp folder under ProgramData??
How can I do that on Install time?
Thanks people...
More info:
Developed with VS2003 VB.NET using the VS Setup Project.
Most likely you'll need to set write permissions for all users during installation.
To test, delete the virtualized folder, manually set the permissions on the ProgramData\MyApp folder and files and see if that works.
As for how to do that pragmatically during installation, that really depends on what technology you're using.
I have had trouble here as well, it seems vista once is decides to virtualize the file, the only way to stop it is to delete the virtual file.
The next time you use it, it will use the ProgramData folder.
I'm trying to build a Windows installer using Nullsoft Install System that requires installation by an Administrator. The installer makes a "logs" directory. Since regular users can run this application, that directory needs to be writable by regular users. How do I specify that all users should have permission to have write access to that directory in the NSIS script language?
I admit that this sounds a like a sort of bad idea, but the application is just an internal app used by only a few people on a private network. I just need the log files saved so that I can see why the app is broken if something bad happens. The users can't be made administrator.
Use the AccessControl plugin and then add this to the script, where the "logs" directory is in the install directory.
AccessControl::GrantOnFile "$INSTDIR\logs" "(BU)" "FullAccess"
That gives full access to the folder for all users.
AccessControl::GrantOnFile "<folder>" "(BU)" "FullAccess" didn't work for me on a Windows Server 2008 machine. Instead I had to use this one:
AccessControl::GrantOnFile "<folder>" "(S-1-5-32-545)" "FullAccess"
S-1-5-32-545 is equivalent to "Users" according to Microsoft Support: Well-known security identifiers in Windows operating systems.
Instead of changing the permissions on directories under Program Files, why not put the logs in a location that is writeable by all users.
See the 4.9.7.7 SetShellVarContext section in your NSIS documentation. You can use it with $APPDATA to get the application data folder that is writeable for all users.
It's an old issue now but as suggested by Sören APPDATA directory is a nice way to do what you want, the thing is :
Don't take user's personnal APPDATA but the "All Users" APPDATA dir!
This way anyone will be able to access the log file ;-)
Also, I read somewhere that using (BU) on the GrantOnFile is not working well with some systems (Win 7 x64 if I remember well), maybe you should use the SID "(S-1-5-32-545)" instead (it's the All Users' SID, this value is a constant on each Windows OS)
One way: call the shell, and use cacls or xcacls.
Why not create a log-directory in the user's %APPDATA% directory? Do you really need to put all the logs in the install directory? Why?