I have installed SFTP on a windows servers using copSSH and all is good and it works well
however you can go back from the main root.
For example when i use C:\copSSH\home{username} as that user i can go back into copSSH and into them directories too.
And I have a user setup to actually be C:\inetpub\wwwroot but that user can go into the system and everything i have this set as my path /cygdrive/c/inetpub/wwwroot
It would be ideal if the user could only go forward from the start directory, rather than out and about there is no write ability but there is read and download....... now for the tags ????
Please make sure the user only has access to "home{username}" folder, and does not have any access to other folders.
Related
What I did
I just started using git, and I think I accidentally initialized a bare repository (instead of a normal one) in my www folder. So when I committed everything, I noticed it started removing everything, which I didn't expect at the time. That's where I made the mistake of killing git. Now there's two files that I can't delete/move/read/write/execute.
When I knew what git was actually doing, I then cloned the git repo in my www folder to my desktop, and it looks like I got most of it back, including those two files, which are normal, and I can write and read to them.
What I'm trying to accomplish
I realize that this may seem like an elaborate scheme to learn how to hack, but that's not the case, I own these files and my goal is to delete them, not break in. I'm unable to delete them however, as killing git seems to have messed up the permissions on the file. I really desperately need to know how to delete them, otherwise git and every backup system I use keep breaking on doing anything in this directory!
Further info:
I'm using Windows 7 Ultimate x64, and Git version 1.8.5.2.msysgit.0
Below a screenshot of the situation:
When I look at the permissions tab in the file properties, I get the message I have to have be an administrative user with permissions to view its security properties. I then clicked on continue, as I have administrative permissions (since it's my laptop). In the newly opened window I get the message I don't have permission to view its security properties. When I try setting its owner, as it suggests, I get the message "Unable to set new owner on [file]. Access denied".
I already tried using an elevated command prompt to try removing them, even forcefully.
I'm desperate, guys (and girls)!
Ok, so I wasn't able to delete the files, on Windows.. I finally did it using a linux (debian 6.whatever) live-cd, and using rm -rf logs/
So if anyone else should encounter the same thing, this is a relatively quick solution.
I'm wanting to compile MySQL into a user-specific directory on my Mac. I know how to compile it and everything, it's just the directory selection I'm looking for. The question starts at:
Is /usr/local user specific? If I installed it into there while on an active user Bob, will Joe be able to see and access it, or only Bob?
I suspect that's not the case. If it is though, then great! If it's not, then where would be the best place to compile and install stuff such that I can have that control over which users can see and access it?
Keep in mind these are for more complicated stuff like compiling MySQL so I don't want them in some generic applications folder (which is why /usr/local would be great if it had this user specific-ness)
/usr/local is system specific... so yes Bob would be able to use it. U usually keep a dir stucture uner my user home so:
/Users/username/
lib/
bin/
etc/
You could install it there. That said you could just modify the user and group settings for the execute permission to a group only you and the system belong to. Im actually thinking that would be the better way to go here since having it in your home dir might make for more hurdles since youll probably want to run the mysql server as a daemon.
I need to write a ini file to the current user's directory in Windows 7 (C:\Users\CurUser). CurUser is not an admin. My installer requires admin privileges. So my setup looks like this:
[Setup]
PrivilegesRequired=admin
When I run the installer it prompts for the admin to login. From that point on, all the user constants, userappdata, etc, are C:\Users\AdminUser... So I need a way to find the CurUser when running the install as AdminUser.
Code examples are appreciated. Thanks.
All user specific files/settings that the app requires should be written by the app if they are found not to exist.
If it needs to come from the setup, you can write it into a global location as a "default" for the app to copy or use.
This also means your app will work for ALL users on the system rather than just the user that ran the setup.
You should split your setup into two parts. The first non-admin part writes the ini file to the current user directory and it calls the second setup part which requires admin priviliges.
In my case, I just switched to {commonappdata} instead of {appdata}, as my data was the same for all users.
I am working on a WinForm application, that allows working to work with "projects" (think about the application as Visual Studio, and projects as VS Solutions).
My question is - where should the application keep its logging files?
Some requirements include:
the application might not be running as an administrator (so saving in the %ProgramFiles% installation folder is not a good option)
The logs should be accessible to end-users (either for review, or for sending to the support team). (This means that hard to find folders, like %AppData%\Company\Application\Version\ProjectName... are not a good solution either)
The application might generate logs even when there are no open projects (so saving the logs in the project's folder is good only when there's a project, but not a final solution).
I was thinking of creating a "working folder" when the application is installed - something along the lines of C:\Application\, and then save the logs in a subfolder, like %WorkingFolder%\Logs\ProjectName
Thanks for the input.
Somewhere in the user's directory is actually the correct place to store them if they are specific to the current running user.
Some programs create folders at the top level of the User's directory, next to Documents and Desktop, others do it in Documents.
Creating it in C:\ might cause issues if the user doesn't have write access to the root directory. You can pretty much guarantee the user will have write access to the Home directory.
The other option is to look for an environment variable, and if its set use the value as the location, if not default to the User's home directory.
If the logs are user only you should store them at %AppData%\Company\Application Name.
If the logs are shared (any user can see any log) you should store them at:
%ProgramData%\Company\Application Name (for Vista+)
or
%AllUsersProfile%\Application Data\Company\Application Name (for XP-)
As for user access, you can add a shortcut to the start menu to the appropriate location or have a link within the program.
Another option in Vista+ is the Public folder (%Public%) which has links throughout Explorer for easy access to.
Where should I write program data instead of Program Files is a good blog entry by Chris Jackson from Microsoft. While it isn't an "official stance" it holds some excellent information.
You can always ask the user to configure this. Set a default path, maybe the application directory. During installation or while setting up the application you may prompt the user to input the path they want to use for logs. That's fair, right. If they're advanced enough to use logs they're good enough to configure a path too.
What do you plan to do with the logs. Are they technical, of for financial/security audits?
The EventLog is a nice place for technical logs, because you can access it remotely (within the Domain) and it is cleaned up automatically.
The %AppData% is also a good place for technical logs, specially if you are unable to connect to the eventlog. You can find the log files, and you can direct the end-user to them, but they are not "in the face" of the end-user. You can include a "send log to the maker" button to receive them.
For logs that needs be accessed by end-users, the My Documents (or a subfolder) looks good.
You can just to add button / menu item to easy open folder with logs.
Best place fo logs are %AppData%\AppName or %temp%\AppName.
Never use %MyDocs% or %Program Files%.
I'd suggest adding that question to the installer so that the user that installs the software can decide where best to put the logs. Though C:\[AppName\ sounds like a reasonable default for your requirements.
Edit: Just thought off, it would probably be worth warning the user if the select a bad location (in Program Files or in the root of the system drive etc) and if they choose to create a new directory, automatically give that directory correct permissions during the installation.
I think %APPDATA%\YourCompanyName\YourAppName is the preferred location. To overcome your stated objection of this location being hard to find, you could pretty easily and quickly implement a simple support screen in your app to allow the end user the ability to access and email these logs without too much trouble, so that the user will not have to remember or manually navigate to the long path name to get to the logs.
I don't really like the idea of the user being able to set this location via the installer because of possible naming and permission issues.
If the app needs to maintain the log only for the users current logged in timespan, then you could keep it in c:/temp.
Most of my winapps, i leave it there, so automatically it gets deleted once the user logs off..
Ofcourse, this primarily depends on your requirement.
Where would be the best "standard" place to put an application's debug log file in a Windows user environment?
In this particular case, it is an application that is run once and could go wrong. It will be run by system administrator types who may need to inspect the log after the application is run. Everytime the application is run, a new log file is created.
Options that have been floated so far include:
The program directory
The user's desktop
The user's local Application Data directory.
I have my favourite, but I wondered what the SO consensus was.
Note: this is similar to this question, but we're dealing with an application that's only likely to be run once by one user.
The Application Data directory would seem to be the perfect place, but it's an area that is nearly invisible. You need to give your users an easy way to get to it.
Have your installation script create a Log folder in the Application Data area for your program, and include a link to the folder in your Start menu.
In the organization I work for we use the (%TEMP% or %TMP%)\CompanyOrProductName\Logs directory
Using %APPDATA% may be problematic with roaming profiles if the logs are numerous or huge : it slows their login process ...
1.The program directory <- not good. Ideally you will only have RX permissions on this folder.
2.The user's desktop <- technically can be done, but I don't like this idea. Polluting desktop... I, as a user, don't like it.
3.The user's local Application Data directory. <- better
My preference is a subdirectory under the program directory (with a clear name like "DebugLog" or something similar). Permissions on that subdirectory should allow creating and writing files ("Change" will be fine)
The "standard" place for the log would be the AppData directory. However, really its up to you where you want to store them. As they are administrator (power users) then there should be no problems storing the logs in the same directory as the application being run. Even in the MyDocuments of the user would be a good shout.
If you EXPECT something to go wrong put it in the user's local Application Data directory.
If you don't and just want to log anyways I might think about really using the temp directory. The reasoning for this is simple. If the application is only run once you will leave trash in the Application Data directory otherwise that nobody will ever need again. In the temp you have at least the CHANCE that it's going to be cleaned up later.
BTW: IMHO the best would be not not create the log AS A FILE at all (log to memory) until something goes wrong. Then you can still offer a dialog where the user selects where to save the log.
Windows Temp Folder
Assuming you want to keep log files around a significant amount of time and they are intended to be used, read I would put the log file in a sub-folder of the user's local application data folder, accessible from windows explorer by typing %localappdata%.
If they are temporary log files, only to be used in the event of system diagnostics then you should put them in the temporary folder, accessible from windows explorer %temp%.