The use case is when a user logged in, the remote directory should direct to his own home directory rather than the root directory.
For example, when Tom logged in, the target directory should be /class12/boy/Tom, and Marry logged in, the directory should be /class12/girl/Marry, rather than /class12.
I do not know which part do I need to modify, I downloaded the source code from http://j-ftp.sourceforge.net/.
Appreciate for your help.
jftp looks like an ftp client:
In short: JFtp is a graphical Java
network and file transfer client.
However, the behavior you desire can only be handled on the server side. EG, for SFTP (over SSH), you need to look into some kind of chroot or jail. For FTP, most daemons usually allow you to configure the paths your user can access, so you would edit the ftpd config file appropriately and restart the ftpd process.
If you do not have access to the server, then you will need to contact your server administrator / provider to make the necessary arrangements.
Related
I have tried for hours to get around this.
I can confirm the database is running, the tables are there, the user 'acore' is created, the password is set correctly and the user has permissions to the acore_auth, world and characters tables, yet no matter what I do, the db_assembler.sh script refuses to run, claiming that the user acore has been denied access.
Heidi SQL Screenshot showing acore user permissions
Resolved:
A prior step in the instructions refers to copying the config.sh file from /azerothcore/conf/dist to /azerothcore/conf and amending it as needed for any SQL information different from the default (I was using port 3308 instead of port 3306). I did that and amended the new config.sh file however the db_assembler.sh script was still looking at the config.sh file in the /azerothcore/conf/dist directory (which had the default settings of 3306).
When I amended THAT file, the import worked perfectly.
I'm currently storing the Jenkins home directory in a Git repository.
The Jenkins configuration has been initialized on a machine A: security settings (authenticated LDAP), global settings, SCM crendentials, etc...
When this Jenkins home is cloned from the Git repository on a machine B, all passwords are encrypted. And unfortunately the Jenkins master that is running on machine B can't read these encrypted passwords.
Moreover, as soon as the configuration is saved, all passwords get re-encrypted, so it seems useless to edit the configuration files manually and put passwords in plain text.
Does anyone has any idea? Thanks!
Got it! Here is the result of my research.
My initial JENKINS_HOME/.gitignore file was as follows:
# Miscellaneous Jenkins litter
*.log
*.tmp
*.old
*.json
# Generated Jenkins state
/.owner
/queue.xml
/fingerprints/
/shelvedProjects/
/updates/
/logs/
# Credentials
/secrets/
secret.key
# Job state
builds/
workspace/
modules/
lastStable
lastSuccessful
nextBuildNumber
But, taken from http://xn--thibaud-dya.fr/jenkins_credentials.html, Jenkins uses a JENKINS_HOME/secrets/master.key to encrypt all passwords, whether in the global settings or in SCM crendentials.
This made me think that the same master.key file was used to decrypt passwords.
So I've tried to remove all credential-related entries from the .gitignore file, thus allowing to push them in my Git repo and then pull them on the machine B (another brand new Jenkins master) and... it works well! All passwords are stored encrypted and since all masters share the same master.key file, all passwords can be decrypted.
Hope it can help someone else!
On a RedHat 6 server, a third party application requires to be root to run and needs access to sqlplus. I have a running database, I can run sqlplus as user 'oracle'. When logged in as user root, 'sqlplus usr/pwd#dbname' works as expected. The trouble is that this agent needs to run sqlplus with no parameters and it always returns ORA-12546: TNS:permission denied.
I've read a dozen times that enabling root to launch Oracle is a security issue but I really have no other choice.
Running Oracle 11.2.0.1.0.
Any help will be much appreciated as I've googled for 2 days with no success.
From the documentation, ORA_12546 is:
ORA-12546: TNS:permission denied
Cause: User has insufficient privileges to perform the requested operation.
Action: Acquire necessary privileges and try again.
Which isn't entirely helpful, but various forum and blog posts (way too many to link to, Googling for the error shows a lot of similar advice) mention permissions on a particular part of the installation, $ORACLE_HOME/bin/oracle, which is a crucial and central part of most of the services.
Normally the permissions on that file would be -rws-r-s--x, with the file owned by oracle:dba, and this error can occur when the word-writable flag - the final x in that pattern - is not set. Anyone in the dba group will still be able to execute it, but those outside will not.
Your listener seems to be fine as you can connect remotely, by specifying #dbname in the connect string. The listener runs as oracle (usually, could be grid with HA, RAC or ASM) so it is in the dba group and can happily hand-off connections to an instance of the oracle executable.
When you connect without going via the listener, you have to be able to execute that file yourself. It appears that root cannot execute it (or possibly some other file, but this is usually the culprit, apparently), which implies the world-writable bit is indeed not set.
As far as I can see you have three options:
set the world-writable bit, with chmod o+x $ORACLE_HOME/bin/oracle; but that opens up the permissions for everyone, and presumably they've been restricted for a reason;
add root to the dba group, via usermod or in the /etc/group; which potentially weakens security as well;
use SQL*Net even when you don't specify #dbname in the connect string, by adding export TWO_TASK=dbname to the root environment.
You said you don't have this problem on another server, and that the file permissions are the same; in which case root might be in the dba group on that box. But I think the third option seems the simplest and safest. There is a fourth option I suppose, to install a separate instant client, but you'd have to set TWO_TASK anyway and go over SQL*Net, and you've already ruled that out.
I won't dwell on whether it's a good idea to run sqlplus (or indeed the application that needs it) as root, but will just mention that you'd could potentially have a script or function called sqlplus that switches to a less privileged account via su to run the real executable, and that might be transparent to the application. Unless you switch to the oracle account though, which is also not a good idea, you'd have the same permission issue and options.
I have a script (Joomla) that creates files and directories on the server. The problem is that it creates them under owner 99 99 (nobody) and after I can't delete or modify them by FTP without the help of the server admin.
I think that is move_uploaded_file function of php.
Is there any solution of this problem by the WHM or by the server admin? Can I modify the default owner in ftp?
What happens is the HTTP server is ran by a user called "nobody", and your FTP user is another one. When the upload occurs, the HTTP server creates the file under its username, and your FTP user has no permission to write (or delete) these files.
The easiest way to fix this (but not really secure) is to add both users in a same group, and change the file permissions to allow users of the same group to read/write on these files.
Your admin should take care of it, but you'll have to call chmod() to change the permissions of your uploaded files.
Explaining it better:
The linux/unix file permissions are composed by permissions of user (u), group (g) and others (o).
I'll only cover 3 types of file permisions here, which are read (r), write (w) and execute (x). So, you end up having something like this:
-rw-rw---x 1 jweyrich staff 12288 Oct 24 00:22 avatar.png
The first rw- is the permission (read/write) of the USER that owns the file (jweyrich).
The second rw- is the permission (read/write) of the GROUP that owns the file (staff).
The --x at the end are the permissions (execute) of the OTHERS users..
Your PHP scripts run as "nobody" user (and by, let's say, "nobody" group), so every file you create from your PHP will be owned by the "nobody" user (and his group). A user can be part of one or more groups.
To solve the permission problem, your FTP user and the "nobody" must be in a common group, let's say the admin put your user in the "nobody".
Once they're in the same group, your PHP script has to give "rw" (read/write) permissions to the "nobody" group members. To do so:
chmod("path_to_your_file", 0770);
The 0770 is equivalent to "u+rwx,g+rwx,o-rwx" , which I explain here:
u+rwx = for user (owner, which is "nobody"), give read/write/execute permissions
u+rwx = for group (which is also "nobody"), give read/write/execute permissions
o-rxw = for others, remove the read/write/execute permissions
After that, your FTP user, which is now part of the "nobody" group, will have read//write access to the uploaded files, and thus can also delete the files. It would look like this:
-rwxrwx--- 1 nobody nobody 12288 Oct 24 00:22 avatar.png
It's not the ideal introduction to unix file permissions, but I hope this helps.
The user that PHP runs under - nobody - is set by the system administrator. There's nothing you can do about that.
You can try chown() to change the file's owner if you know the FTP user's ID. Usually though, you will not be allowed to do this from within PHP.
Depending on the group situation on the server, it could be that if you use chmod to change the file's access rights after the file has been uploaded, the FTP account can access the file:
Try this first:
chmod($uploaded_file, 0660); // owner+group read+write
If that doesn't work, try this:
chmod($uploaded_file, 0666); // global read+write
one of these should make the file usable by the FTP account.
The 0666 is highly discouraged because other users on the server could write into your files, but in some configurations, it's the only way to get going.
Is it possible to give asp.net read permission to the certificate store?
If yes , how?
If no... do I need to set the permission manually per certificate file?
If yes where are these files physically on the HDD?
Generally you give permissions to A certificate. I use a method like this to find the custom made cert and grant permissions. If you are using a cert issued by a public entity like Verisign, Thawte, etc, this is probably unnecessary.
FindPrivateKey.exe My LocalMachine –n "CN=<certificate issuer>"
...will find certificates on the local machine in the personal store for a particular issuer.
Note: If FindPrivateKey is not on your local machine,
download the WCF samples, including the FindPrivateKey tool, at
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21459
FindPrivateKey returns the location of the private key for the certificate, similar to
"C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machinekeys\4d657b73466481beba7b0e1b5781db81_c225a308-d2ad-4e58-91a8-6e87f354b030".
Run the following command line to assign read only access permissions to the process identity of the ASP.NET/WCF Service
cacls.exe "C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machinekeys\4d657b73466481beba7b0e1b5781db81_c225a308-d2ad-4e58-91a8-6e87f354b030" /E /G "NT AUTHORITY\NETWORK SERVICE":R
NOTE: If you are running Microsoft Windows® XP, give the certificate permissions for the ASPNET identity instead of the NT Authority\Network Service identity, because the IIS process runs under the ASPNET account in Windows XP.
Certificates are viewable from the MMC snap in for Certificates. Open MMC, choose File --> Add/Remove Snap in, click the add button and choose certificates. From here you will need to choose the appropriate store (usually Computer Account - Local Computer for ASP.NET items) to manage and then you can view/admin the certs.
Please take a good hard look at the different command line options, and make sure that you have a clear understanding of what certificates are and how they work before granting any permissions.
The network service account that asp.net run under by default doesn't have access to the local machine personal certificates. Grant access by the following:
Repost from Sohnee # forums.asp.net
Step 1 - if you don't already have it
installed - get WinHttpCertCfg
Step 2 - if you already have the
certificate installed on the machine
and you just need to grant access to
Network Services:
WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s "IssuedToName" -a "NetworkService"
Don't really like answering my own questions, but one simple way to get rid of this error is just to give network service full access to the c:\drive, and propagate permissions down.
You'll shoot me down I know, telling me how bad this is - but it works.