openSSH, user permissions for PHP files.

Nzo · 10-25-2008, 07:32 AM

Is it possible to allow a user to have execute permissions, but then block them from reading, writing, moving and copying that same file?

Thanks.

Nzo · 10-25-2008, 09:21 AM

anyone at all?

estabroo · 10-25-2008, 10:54 AM

well you could do chmod 111 filename, that'll prevent most of what you want (read, copy), writing is sort of blocked, moving and deleting (along with writing) are driven more by the directory permissions then file permissions. The reason I say writing is sort of blocked is that, while the file itself wouldn't be writable, it could be replaced with one that is via a move or delete.

custangro · 10-25-2008, 12:02 PM

Quote:

Originally Posted by estabroo

well you could do chmod 111 filename, that'll prevent most of what you want (read, copy), writing is sort of blocked, moving and deleting (along with writing) are driven more by the directory permissions then file permissions. The reason I say writing is sort of blocked is that, while the file itself wouldn't be writable, it could be replaced with one that is via a move or delete.

That would be the way that I do it...

Also you can look at setfacl

man setfacl for more info...

-C

estabroo · 10-25-2008, 05:21 PM

Also you can make it immutable with chattr as root. chattr +i filename
This will probably do exactly what you want.

excerpt from chatter manpage:
A file with the `i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be
written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Nzo · 10-26-2008, 12:55 PM

I tried chmod 111 file.php, so the permissions are like this:

Code:

---x--x--x

then I try to execute:

Code:

php file.php

and i get

Code:

Could not open input file: file.php

I tried

Code:

chattr +i file.php

but the script was still readable, but uneditable. I want to be able to prevent users reading the file, but allow them to execute it.

I also looked at setfacl, doesnt this do the same as chmod?

Thanks for your suggestions!

Nzo · 10-26-2008, 01:10 PM

Another way I could get round this, is give the user read and execute permissions (-r-x) so that the file will run, then only allow them to use the command: "php file.php".

That way they wont be able to "vi file.php" and read the file contents, and also wont be able to use commands to copy or move the file to a different directory or computer.

How can I prevent all commands apart from "php file.php" for a user?

custangro · 10-26-2008, 03:15 PM

Quote:

Originally Posted by Nzo

I also looked at setfacl, doesnt this do the same as chmod?

Thanks for your suggestions!

Not exactly....it's more granular than just the chmod/chown/chgrp commands...

You can set the owner and group to be you (and your group) but give perms to others...

Example

Code:

root@host# chmod 550 file.php
root@host# chown me:me file.php
root@host# setfacl -m group:<groupname>:--x file.php

OR

root@host# serfacl -m user:<username>:--x file.php

Where <groupname> is the name of the group and <username> is the name of the user.

jschiwal · 10-26-2008, 05:00 PM

A file needs to be read to be able to be executed. You can set the immutable bit.

What are the permissions of the directory the file is in? That will determine whether the file can be deleted. If the user has write permissions on the directory, (such as in /tmp) then set the "sticky" bit on the directory. Deleting and saving files in a directory is a write operation on the directory. The sticky bit will prevent one user from deleting files owned by other users (except for the root user).

Using SELinux, you can protect a file even from root, unless the root user explicitly modifies the security attributes of the file.

You can't prevent an executable (permitted) file from being read, and thus copied. The only way around this, that I can think of, is to have it executed by proxy. E.G. client/server. Maybe you could have a stub program that assumes the euid or egid of the caller (for permissions) and executes it as if it were the user. The target program would be in a directory inaccessible by the user.

Maybe you could explain what this file is and why you don't want it copied but want it executed by a user. If you have a script that has username/password info in it, then your problem isn't disallowing the reading of the file. World readible scripts should not have authentication information in them. For example, never have "username" & "password" options in /etc/fstab. Use the "credentials" option instead, referencing a file that only root can read.

Nzo · 10-26-2008, 10:07 PM

ok I understand setfacl a bit more now.

The reason I want to keep the file unreadable but allow access is because I have a hosted web server, which will receive data, then connect via a PHP script using SSH to another server, and send the data in variables by running a command like so:

Code:

php file.php vone vtwo

I dont want people copying or hacking my processing PHP code!

So if anybody with access to the hosted web server takes my ssh username and password, connects to my remote server via SSH, they can do whatever they want as that user.

Other ways I thought about sending the data was in html form posts, but i dont have a SSL certificate (the data needs to be safe). I could encrypt at one end and decrypt at the other using the built in PHP functions...

I also want to prevent random people from sending my remote server fake data to process, but I think ill check which IP the data is coming from in my PHP script.

Any ideas on other ways I can get data server-server securely + quickly using PHP/linux/ssh?

estabroo · 10-27-2008, 08:27 AM

You could always make a suid C wrapper that executes your php. This would allow you to make the php have permissions that make it unreadable by the user but still executable.

Setting 111 permissions for compiled programs works fine, you don't need read permission to execute them. I'd forgotten that scripts need to be readable since they get loaded by an interpreter.