Articles of Suexec

Suexec,可写组的文件

我正在使用Suexec运行Apache服务器。 但是,如果我尝试执行可写组的CGI脚本(如果我chmod gw,脚本运行良好),则会出现内部服务器错误。 但是,我希望该文件是可写组的。 SuPHP有一个configuration选项,允许我这样做,但是我找不到Suexec的类似选项。 我如何运行g + w的CGI脚本?

SuExec for Tomcat?

我们正在运行一个(基于cPanel / WHM的)服务器,主要包含PHP应用程序。 他们使用Apache的suExec组件的所有者的权限执行。 我们正在考虑将我们的一些核心应用程序转移到Java,运行在Tomcat(使用Apache代理),这显然可以很容易地从WHM内部安装。 但是,有没有办法在那里保留suExecfunction,所以Java应用程序也可以使用正确的权限执行?

suexec和文件根目录问题

我在apache2下运行FastCgiServer时遇到了问题。 当我定义一个configuration了静态fcgi服务器的虚拟主机时,我从suexec得到一个错误: command not in docroot (/var/www-blah/dispatcher.fcgi) 这是正确的,因为docroot是/var/www 。 但是当我使用由AddHandler魔术生成的dynamicfastcgi时,我也使用suexec ,即使脚本位于/home/…/public_html/dispatcher.fcgi也不会出现同样的问题。 是什么导致suexec在那里正确运行? 我怎样才能在虚拟主机上复制该行为? 更新:其实,我把我的东西从/var/www-blah到/var/www/blah ,所以它在docroot下工作。 我想suexec有一些public_html检测。 但是仍然不起作用的是在/var/www/…下使用suexecdynamic的fastcgi。 即使脚本属于正确的用户,suexec不会显示任何错误,似乎也不会运行(脚本工作为www数据)

SuExec:“命令不是在docroot”即使它是?

Arch Linux 2011.08.19(Linux 3.4.2 i686) 带有SuExec的Apache 2.2.22 PHP 5.4.4(cli)通过FastCGI 我的网站都工作得很好…我不知道什么时候发生了,因为我注意到它在一个星期后(我猜也许在系统升级后),但所有我的VirtualHosts脱机与可怕的“脚本的提前结束头文件:php-fcgid-wrapper“500错误。 SuExec日志给了我这个每个网站: [2012-07-16 00:45:02]: uid: (1001/site) gid: (1001/site) cmd: php-fcgid-wrapper [2012-07-16 00:45:02]: command not in docroot (/var/www/site/fcgi-bin/php-fcgid-wrapper) 这不是(或者至less不应该)是真的…我用–with-suexec-docroot=/srv/www设置自动编译Apache 。 不过,我尝试了一个理智的检查,看看SuExec实际上认为它有什么文字根据: $ suexec -V suexec policy violation: see suexec log for more details 对于这些日志声称: [2012-07-16 01:07:52]: too few arguments 用sudo试了一下 一样。 所以,即使这样做没有意义,也不能正确地诊断问题。 我尝试的另一件事是将所有内容从/srv/www移动到默认文档根目录/var/www ,以查看在升级过程中是否可能恢复为原始存储库版本。 更新我的VirtealHosts,重新启动Apache,但仍然有相同的500错误。 还有什么可能导致这个?

用suexec作为PHP文件的所有者运行PHP脚本的安全问题

我正在使用suexec来确保PHP脚本(以及其他CGI / FastCGI应用程序)作为与相关虚拟主机关联的帐户持有者运行。 这允许保护每个用户的脚本不被其他用户读/写。 但是,我发现这样做会带来不同的安全漏洞。 以前,Web服务器作为非特权用户运行,对用户文件具有只读权限(除非用户由于某种原因更改了文件权限)。 现在,Web服务器也可以写入用户的文件。 因此,虽然我阻止了不同的用户利用对方的脚本,但是我已经做到这样,如果某些应用程序存在远程代码注入漏洞,现在它不仅具有读取权限,而且还具有对所有用户脚本和网站。 我该如何处理? 我有一个想法是为系统中的每个用户帐户创build第二个用户帐户,以便每个用户都有自己的用户帐户,并且他们的所有脚本都在另一个用户帐户下运行。 但是这似乎很麻烦。

fcgid,suexec和userdir

我正在尝试使用fcgid设置每个用户的trac实例。 问题是trac需要rw访问trac实例,所以我需要fcgi进程在相应的用户下运行。 我安装了suexec,fcgid和userdir Apache模块(在Debian上)。 我提出了vhost指令 ScriptAliasMatch /~(.*)/trac /home/$1/public_html/trac.fcgi 这个工作在trac.fcgi运行,但不幸的是,在www数据用户。 我如何让fcgid在$ 1用户下启动它?

为什么限制Apache用户执行脚本?

当Apache用户被允许通过PHP执行bash脚本 – 为什么它被认为是危险的? 我知道用户可以遍历整个文件系统,甚至可以看到机器上托pipe了哪些用户。 他们也可以读取conf/httpd.conf的设置。 但是,这些信息将如何帮助他们破解系统? 考虑suexec是活跃的。

仅针对PHP文件拒绝访问

具有SuExec下的VirtualHosts的Apache HTTP Server 2.2.21 PHP 5.3.8通过fcgid Arch Linux 2011.08.19 任何时候当我尝试访问一个PHP文件时,我都会从Apache获得403访问被拒绝的错误。 HTML文件和文本文件工作正常。 我已经玩过了我能想到的PHP文件(从644到777)的所有可能的权限组合。不会改变任何东西。 我也玩FCGI包装和父文件夹的权限。 用o + x(777,775,773,771),我在浏览器中得到这个: 访问被禁止! 您无权访问请求的对象。 它是读取保护的或不可读的服务器。 …这在虚拟主机错误日志中: 客户端被服务器configuration拒绝:/ srv / www / hostname / fcgid-bin / php-fcgid-wrapper 用牛(776,774,772,770或以下),我在浏览器中得到这个: 被禁止 您无权访问此服务器上的/fcgid-bin/php-fcgid-wrapper/index.php。 此外,尝试使用ErrorDocument处理请求时遇到403禁止错误。 …这在日志中: (13)权限被拒绝:访问/fcgid-bin/php-fcgid-wrapper/index.php被拒绝 这真是令人难以置信的看到,因为我的设置工作正常,直到我开始得到这个,我不知道我可能会做什么来改变这一点。 /usr/bin/php-cgi和wrapper都可以在直接调用完全相同的input文件时正常工作。 这是我的虚拟主机configuration: <VirtualHost *:80> ServerAdmin [email protected] DocumentRoot "/srv/www/hostname/public/" ServerName hostname.com ServerAlias www.hostname.com SuexecUserGroup hostname hostname ErrorLog "/srv/www/hostname/logs/error.log" LogLevel […]

如何在不同的用户下运行每个站点?

比方说,我有一个服务器和一群开发人员在不同的网站上工作(PHP和Django的),我不希望不同的开发人员访问对方的网站。 我应该如何去实施这样的解决scheme? (有些指针会做)

在Centos 6上设置Apache 2.2 + FastCGI + SuExec + PHP-FPM

我试图在这里遵循这个非常详细的说明 ,我只是从www-data用户更改为apache用户,并使用/ var / www / hosts / sitename / public_html而不是/ home / user / public_html 不过,我花了整整一天的时间,试图找出为什么php文件内容显示不正确的分析。 我似乎无法解决这个问题。 以下是我目前的configuration: /etc/httpd/conf.d/fastcgi.conf User apache Group apache LoadModule fastcgi_module modules/mod_fastcgi.so # dir for IPC socket files FastCgiIpcDir /var/run/mod_fastcgi # wrap all fastcgi script calls in suexec FastCgiWrapper On # global FastCgiConfig can be overridden by FastCgiServer options in […]