nginx 反向代理 java递归创建文件及文件夹 导致 创建的文件对于nginx用户无权限访问的问题

  1. java上传文件可以设置访问权限 File类
    部分代码
File uploadPath = new File(imgPath+path);
if(!uploadPath.exists()) {    
        uploadPath.mkdirs();
}
//Process process = Runtime.getRuntime().exec("chmod 777 -R " + uploadPath);
log.info( process.toString());
String uploadFileName = path+"/"+ getUUID()+"."+imgend;
File uploadFile = new File(imgPath+uploadFileName);
uploadFile.setExecutable(true,false);//设置可执行权限  
uploadFile.setReadable(true,false);//设置可读权限  
uploadFile.setWritable(true,false);//设置可写权限

其中java执行shell脚本方式

Process process = Runtime.getRuntime().exec("chmod 777 -R " + uploadPath);

不知道为啥没生效
此种方式虽然对当前文件起作用 但是对于递归创建的文件夹并不起作用

uploadFile.setExecutable(true,false);//设置可执行权限  
uploadFile.setReadable(true,false);//设置可读权限  
uploadFile.setWritable(true,false);//设置可写权限

后来发现 tomcat是用root用户启动的,nginx也是root用户启动的 查看文件夹 也是root用户有所有权限
后来发现是nginx的配置问题 nginx的worker process 用户并非root

Nginx用户权限

在nginx.conf文件的第一行一般是设置用户的地方(编译安装nginx时的参数--user=也是指定用户的地方),如 user www www;

如不指定默认是nobody. 这里用户的设置又有什么意义呢?主要是指定执行nginx的worker process的用户,linux里所有程序都是文件,都具有权限问题,这个指定的用户对特定的文件有没有权限访问或执行,就是这个用户的意义。

先来了解一下 Nginx的用户管理
(1) Nginx在以Linux service脚本启动时,通过start-stop-domain启动,会以root权限运行daemon进程。
(2) 然后daemon进程读取/etc/nginx/nginx.conf文件中的user配置选项,默认这里的user=nginx,也就是用nginx用户启动worker process。403错误就是因为nginx用户没有权限访问我当前开发用的用户目录,/home/dean/work/resources。
解决方法是将user=nginx替换成root,然后重新启动nginx,可以了。
其他方法也试过,比如给/home/dean/work/resources目录设置777权限,比如将nginx用户加入root组,都不行。所以当开发的时候,就用user=root配置吧。至于产品环境下,resouces目录完全可以放到nginx用户目录下,所以问题不大。

举例2:访问速度慢 nobody用户导致
nobody 是系统用户,是一个不能登陆的帐号,一个特殊用途的用户 ID ,一些服务进程如apache,aquid等都采用一些特殊的帐号来运行,比如nobody,news,games等等。一般来说 uid < 500 的都是系统 ID 。
Linux 系统为了安全,很多操作和服务的运行都不是运行在 root 用户下面的,而是一个专用的 ID ,这个 ID 一般就是 nobody ,这样就可以把每个服务运行的情况隔离出来。保证不会因为服务器程序的问题而让服务器程序成了黑客的直接操作源(黑客拿下了服务器程序,也仅仅是 nobody 用户而不是 root 用户)。同时也不会影响其他用户的数据。
服务器程序提权有专用的办法来防止恶意使用的。
除了 nobody ,常见的还有 ftp 、ssh 什么的。有的不是用来跑服务,而是用来占坑,主要是用用户组的权限管理进行权限设置,这个时候会有一个占坑用的同名 ID 加入到用户组。这种情况好像主要是为了兼容。
问题描述:

上午业务人员反映,系统响应很慢,界面要刷新很久才出得来。查后台也没有报什么错,我们系统是用nginx做负载均衡。惯性地不走负载均衡而直接访 问单节点应用,发现响应很快,很正常。初步定位问题出在nginx上,然后查nginx日志,发现有很多错误,错误中有“13: Permission denied”这个信息,明显是权限问题,很奇怪,之前运行都很正常啊。后来一问才知道,维护人员做了操作。

系统上nginx安装时使用的是root用户,也是用root用户启动的,所以要修改配置的时候需要使用root用户,管理上不方便,所以维护人员 心血来潮修改了nginx的权限(后来知道他是使用这个命令修改的权限chown -R user:group $nginxdir)。就是将nginx的用户和组都换掉了,但是这样为什么会造成“响应慢”呢?

问题原因及解决:

前面提到在linux上有些应用程序的一些进程会默认使用nobody这个用户来启动,以保安全。nginx有两种进程,除主进程之外的工作进程都 是用nobody这个用户启动的(nginx工作进程的数量使用worker_processes这个参数来设定)。而工作进程要访问nginx下这两个 目录client_body_temp和proxy_temp(这两个目录按我的理解是缓存一些静态文件,比如图片或者css文件什么的,以提高 nginx访问速度),权限变更后,造成工作进程访问不了这两个目录下的内容,造成某些图片和连接打不开,就像响应很慢一样。将权限变更一下就OK了。

你可能感兴趣的:(nginx 反向代理 java递归创建文件及文件夹 导致 创建的文件对于nginx用户无权限访问的问题)