Disabling certain commands/programs in certain folders? - unix

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.

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.

Eucalyptus 3.4.2 CentOS 6 demo root password

I installed cloud-in-a-box/fastrack of Eucalyptus and am able to create instance and log into it. But when trying sudo, sudo su - or login in as root I'm asked for a password. I'm not sure what the password might be. Does anyone know what the default password for the Image is?
I think this is how the image is designed. It uses the cloud-user account only and has no root access, nor does it allow sudo.
There are other starter images available that can be "installed" that have sudo as root enabled. In those cases you simply issue
sudo su -
and you become root.
To see what is easily available use:
eustore-describe-images
As a note, some of the other starter images have different accounts (not cloud-user), such as ec2-user. If you don't know which account to use simply try to ssh into the instance as root and it will usually get a message back telling you:
Please login as the user "ec2-user" rather than the user "root".
I am not sure if there is a password on the root account in that image. Regardless, the recommended way to log into instances is by creating an SSH key (euca-create-keypair KEYNAME >KEYNAME.pem), specifying it when running an instance (euca-run-instance -k KEYNAME), and then logging in using the key generated (ssh -i KEYNAME.pem root#INSTANCE-IP). You'll probably have to change the permissions on that .pem file before SSH will allows you to use it (chmod 0600 KEYNAME.pem). The instance obtains the public portion of the key from the cloud at boot time and adds it to the authorized_keys file.

How can I delete all blocked users with Drush?

How can I delete all blocked users with Drush? I have hundreds of blocked users from spammers. I want to delete all these users. I tried doing it through the web interface, but this only works for about 20 users at a time. I have 60 pages to delete, which takes too long and is unsustainable. Also, I want all the relevant callbacks to be run when a blocked user is deleted, and I want all its content deleted. I noticed user-cancel, but this appears to only apply to a single user. Is there a way to make this command work with all blocked users?
Using Drupal 7 and Drush 5.9, the way I did was:
1- Create an alias "#example-local" to your local Drupal installation, as shown here.
2- Create a script file called "delete-blocked-users.script", at, say, "/Users/username/scripts/drush", with the following code:
#!/usr/bin/env drush
$users = db_query("SELECT * FROM {users} WHERE (status = 0)");
foreach ($users as $user) {
exec("drush #example-local user-cancel $user->name -y");
}
3- Make the script file executable with:
chmod +x ~/scripts/drush/delete-blocked-users.script
4- And finally, run the script using:
drush #example-local scr ~/scripts/drush/delete-blocked-users.script
This will delete all the blocked users (users with status = 0), without asking for confirmation (defined by the -y flag).
Drush does not have a simple command to delete all blocked accounts. It would probably be easier to set up a vbo view in you admin interface that lets you filter for blocked users then you can select all and cancel.
You can also run a php script with drush php-script script.php.
So you can set up a php script that does a query for blocked users then loops through though users and calls the user cancel function.
Besides drush, is just easier access to mysql data using user, password and database name that you can find in file drupalhomedir/sites/default/setting.php with command:
mysql -u username-at-setting -ppassword-at-setting database-at-setting
then delete all records on drupal 'user' table with:
DELETE FROM user WHERE status=0;

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.

CODA setting owner & group [duplicate]

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.

Resources