Apache not allowing me to enter folders belonging to other users

匆匆过客 提交于 2019-11-28 14:32:24

I can't find any official link for this, but according to this site:

All Files & Directories MUST be owned by your username, and not "nobody" or some other name/number. If it is not owned by you, suPHP will refuse to run the script and produce an "Internal Server Error 500".

I can understand files, but I don't see the need for directories to belong to you. I have found one patch online (see here), however, I don't know if it works or not as I have not tested it yet.

EDIT: There is a way to allow users to access scripts outside of their docroot (via suPHP_GlobalDocRoot). I can't get it to work for me, Apache claims it is a syntax error. In any case, even if it did work, It would still require at least execute access 0111 (and possibly also read 0555) on all the directories all the way up to /.

Therefore, I am pretty confident there is absolutely no solution to my problem. I am therefor accepting this as the answer. I will select another answer if someone manages to provide one.

I could be wrong, but if suPHP works the way I remember, then PHP is running under the user (in this case user1) not as Apache (www-data), in which case www-data)is the only one with read and write access to the validate file and user1 is not www-data.

The solution, I think, would be to grant read permission to all for validate and write permission only to www-data. So:

/var/www/
└── [drwx------ user1  ]  user1
    ├── [-rwx------ user1  ]  index.html
    └── [dr-x---r-- www-data  ]  validate
        └── [-rwx------ user1  ]  validate.php

With the above, user1 can not edit their validate file, only read it.

You might also want to try:

/var/www/
└── [drwx------ user1  ]  user1
    ├── [-rwx------ user1  ]  index.html
    └── [dr-x-----x www-data  ]  validate
        └── [-rwx------ user1  ]  validate.php

I always confused on how exactly "execute" works, but I believe the idea is that the file can be run (executed) by the user, but not read or written to. But this would require validate to be executable, so if it's a script, that may not work. Someone else here might be able to confirm.

There are quite a few configuration options for suPHP, and without them I can't give an exact answer, so I'll assume that you are running a pretty std configuration, because if you don't have it set up pretty strictly then you introduce so many exploitable holes that there isn't much point in using it.

  • PHP scripts must be owned by non-privileged UID
  • The path backward to / must be own by the same UID or root.
  • If the script or any parent directory cannot be writeable by other the user UID.
  • The script is executed in the users UID.

This is part of the formal assurance model of suPHP and if you want to change it, then don't use suPHP.

The user can define his/her own path for loading PHP.ini. By default the user can specify a custom php.ini and IIRC you can't disable the suPHP_ConfigPath option. After all at the end of the day, you are running php-cgi in the users UID. So this mean that even if you establish an auto_prepend_file (which could be owned by root and not writeable by the UID) then the knowledgeable user could still bypass this.

My simple Q is why are you using PHP, or at least the suPHP established PHP handler to do what you are trying to achieve here? Keep PHP for the user and user privileged functions. Use a CGI script or even a RewriteMap and a prg: option for these "systemy" functions. You could even trivially implement this in PHP if this is your preferred language as this would be executed using php-cli. There are lots of tutorials on how to write Map prg functions. They're pretty easy to implement.

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!