CODA setting owner & group [duplicate] - wordpress

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.

Related

How to grant one particular user read access to a unix file

I want to give one particular user read access to a file on a unix machine. I am not root so I guess I can not do chown.
I tried searching for something that uses chmod, but there it looks like I can't specify a particular user, only a one-self, group, or all.
I guess this was asked before already, but I couldn't find anything.
Generally when you want more fine-grained permissions in Linux, you should use Access Control Lists. The Arch Wiki has a good guide on how to set it up.
Once set up, you can define more complex rules for modifying the access control policies for your mounted filesystem.
You can set these rules with commands that look like: setfacl -m "u:johny:r-x" abc.
This says "Give (user) Johny read and execute permissions to the file/directory specified by the path abc".
You would then also be able to see the permissions for a filesystem object using getfacl
root#testvm:/var/tmp# getfacl appdir/
# file: appdir/
# owner: root
# group: appgroup
user::rwx
group::rwx
group:testusers:r--
mask::rwx
other::r-x
In this example you can see the default for any user/group which is not (in) the testusers group, can read, write, or execute the directory. But testusers can only read.
The traditional, Unix way is, as you suggest, to chown the file and set permissions that way.
You might also be able to use access control lists (ACLs). Have a look for the getfacl and setfacl commands (link). The bad news is that ACLs are not always enabled and the default OS install doesn't always include the commands, which doesn't help you if you don't have root.

How to configure Oracle 11g to launch sqlplus?

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.

Disabling certain commands/programs in certain folders?

Is there anyway to deny access to certain commands and executables while in a certain folder?
Specifically, I am trying to deny the access of pwd while in certain folders, so that users that access the folder via a symlink cannot see where in the file hierarchy they are (in order to prevent some security issues), but are able to use retain use everywhere else.
You can move pwd to another directory and make a script called pwd like this:
provided new location of real pwd is /path/to/movedpwd:
#!/bin/sh
if test /path/to/movedpwd = UNWANTED_DIR
then echo "Forbidden dir!"
else pwd fi
Then make it executable-only so that the users cannot find the real pwd.

A usage of setuid?

I read a Powerpoint slide recently, and can't get a clear concept about the usage of setuid.
Here is the content of the slide.
Setuid example - printing a file
Goals
Every user can queue files
Users cannot delete other users' files
Solution
Queue directory owned by user printer
Setuid queue-file program
Create queue file as user printer
Copy joe's data as user joe
Also, setuid remove-file program
Allows removal only of files you queued
User printer mediated user joe's queue access.
Here are my questions.
I don't have a clear ​understanding​ how to solve this problem by "setuid".
First, if the file is created by user printer, how does user joe copy data to a file owned by printer. Does it have some certain right to this file.
Secondly, how to identify the relationship between you and the file you queued.
Does the file's state show something, but the file is owned by printer, which can only be changed by root. Does it have something to do with the file's gid? If so, other users' gid may also be related to this file.
Does the file's context show something about who queued it?
My questions are a mess, and I really don't have a clear concept about the solution.
Let's assume that the files are to be stored in /var/spool/pq directory; the permissions on the directory printer:printgrp:2700 (owner printer, group printgrp, mode 2700 - read, write, execute for owner only, and the SGID bit set on the directory means all files created in it will belong to group printgrp).
Further, we assume that the print queuing program, pq, has permissions printer:printgrp:4511 (setuid printer, anyone can execute it, but only printer or root can look at it).
Now, suppose Joe runs pq /home/joe/file, and the permissions on the file are joe:staff:600 (only Joe can read or write to the file). Joe's umask is set to 022 (though this file has more restrictive permissions than are implied by the umask).
When the program runs, the real UID of the process is joe, but the effective UID is printer. Since there is no need for setgid operation here, both the real and effective GID are staff. Joe's auxilliary groups list does not include printgrp.
Note that it is the effective UID and GID of a process that control its access to files. On his own, Joe cannot see what jobs are in the printer queue; the directory permissions shown don't even allow him to list the files, or access the files in the directory. Note that the converse applies; on its own, the printer user (or the pq program running as that user) cannot access Joe's file.
The pq program can create files in the printer queue directory; it will probably create two files for this request. One will be a control file, the other will be a copy of the file to be printed. It will determine a job number by some mechanism (say 12345) and it might create and open two files for writing (with restrictive permissions - 0600 or even 0400):
/var/spool/pq/c.12345 - the control file
/var/spool/pq/d.12345.1 - the first (only) data file
It should then reset its effective UID to the real UID, so it is running as Joe. It can then open the file Joe asked to be printed, and copy it to the data file. It can also write whatever information it deems relevant to the control file (date, time, who submitted the request, the number of files to be printed, special printing options, etc). When it closes those files, Joe is no longer able to access them. But the program was able to copy Joe's file to its print queue.
So, that addresses questions 1 (permissions) and 2 (control information), and also 4 (control information again).
Regarding question 3, root is always a wild card on Unix-like systems because can do anything that he wants. However, as suggested by the rest of the answer, the control file contains information about the print request, including (in particular) who submitted it. You can use setgid programs instead of setuid programs; these work in analogous ways. However, under the system I postulated, the group permissions essentially didn't come into the picture. The pq program set the permissions on the control file and data file such that the group can't read it, and the directory permissions also deny group access.
We can postulate two more programs:
pqs - printer queue status
pqr - printer queue remove
These programs would also be setuid printer. The pqs program can read the control files in the directory and list pertinent information from them. The pqr program can read the control files to ensure that when Joe submitted job 12345 when he requests the removal of job 12345. If the program is satisfied, then it can delete the files.
Separately from these user-invoked programs, there would also be a daemon program (conventionally named pqd in this system) that would be kicked into action by pq if it is not already running. It would be responsible for reading the control files in the directory, and using that information to actually print the data files to the relevant printer. The details of how different printers and different data formats are handled are a problem for the daemon to deal with. The daemon too will run with printer privileges, and printer will have been given access to the printer devices (for locally attached printers) or configured to communicate over the network with a protocol such as IPP (Internet Printer Protocol). Joe probably won't be able to use the printer devices directly.
Note that the setuid programs have powers that Joe does not have. They must be written carefully to ensure that Joe cannot abuse those extra powers. Any setuid program is somewhat dangerous; a setuid root program can be lethal. In general, setgid programs are less dangerous. However, for both types of program, great care is required in the writing of such programs.

Please give me some info about modify jftp code

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.

Resources