CentOS普通用户拷贝无权限访问的文件的脚本实现及其配置
业务需求：收集项目需求信息，如操作系统日志、项目工程及项目工程日志、数据库信息和数据。
环境：CentOS6.7 x86_64
程序流程：程序MyInfoCollector是一个信息采集程序，由另外一个进程MyMonitor守护执行，MyInfoCollector程序收集信息不定，为避免后期新需求导致更改代码，所以加入配置文件MyInfoCollector.xml，该配置文件配置执行脚本路径，程序运行自动调用脚本实现需求。
问题：My.sh：收集项目日志（MyInfoCollector.log），结果：成功！
System.sh：收集系统日志及数据库日志（/var/log/messages*和/var/log/mysqld.log），结果：无效。
用户名：adz，普通用户，adz用户组，不考虑将adz赋予更高的权限。
思考：权限问题 （后面引发免密问题、切换root用户问题、自启终端问题、系统日志加入读权限问题，sudo免加载终端问题）。
解决流程：
System.sh：
#!/bin/bash cp -fp /var/log/messages* ./ zip -r -j -p -m -8 System.zip ./messages*
执行：
【思路1：权限问题，加入sudo来处理】
System_root.sh：
#!/bin/bash sudo cp -fp /var/log/messages* ./ sudo zip -r -j -p -m -8 System.zip ./messages*
执行：
需要人机交互来输入密码，由于脚本是程序带起，需要跳过输入密码的交互阶段，需要解决免密问题
设置用户部分工具sudo免密功能
切换为root，执行vim /etc/sudoers或者visudo，加入行(箭头处)
执行：
成功！！！
此时，应该可以解决问题了。
悲剧的是，程序带起时仍然没有看到压缩包！！？？
【思路2：直接切换root用户】
换个思路，切换root账户来处理
使用spawn expect转换root用户
需要安装tcl+expect，安装光盘中有
安装：rpm -ivh tcl-8.5.7-6.el6.x86_64.rpm expect-5.44.1.15-5.el6_4.x86_64.rpm
SwitchRoot.exp
#！/usr/bin/expect
MyPassword=123456
spawn su root
expect "password:"
send "${MyPassword}\r"
send "./System.sh"
interactSystem.sh
#!/bin/bash cp -fp /var/log/messages* ./ zip -r -j -p -m -8 System.zip ./messages*
该脚本手动执行没有问题，但是程序带起时仍然无压缩包生成。与上个思路最后的结果相同，不再附带图片
【思路3：自启动终端】
既然手动执行可以，程序带起有问题，难道是程序执行环境有问题？
不多说，手动执行MyInfoCollector 后: cat /proc/pid/environ > environ_self
被MyMonitor带起执行MyInfoCollector 后: cat proc/pid/environ > environ_auto
由于东西太多，暂不贴图了，发现手动执行时有gnome相关环境，带起执行时没有这个gnome环境，自建一个shell来执行脚本？开干！
设置启动终端功能
testShell.sh
#!/bin/bash gnome-terminal -e 'bash -c "bash System_root.sh"'
System_root.sh
#!/bin/bash sudo cp -fp /var/log/messages* ./ sudo zip -r -j -p -m -8 System.zip ./messages*
手动执行没问题！ 自启动直接显示错误了，（此处后期加入了错误日志输出，可以看到gnome-terminal执行结果日志为“无法处理参数：无法打开显示，返回值为1”）
此路不通！
【思路4：无权限文件加读权限】
系统默认情况下的messages*只有root用户有读写权限，其他用户没有读权限，需要设置一下，起初以为只要将/var/log文件夹设置为可读即可，然而并不然，其本来就可读。那就只能设置具体的日志权限了。
系统初始文件情况：
设置文件日志可读
Root账户打开/etc/logrotate.d/syslog：将红色箭头部分插入文件：
删除/var/log/messages*
重启rsyslog服务：
重启后可以看到日志支持普通用户读取了
结果可喜，当前需求解决，但是mysqld.log如何处理，如果后期有其他文件也需要怎么处理，显然该方案只能解决一时之需。不可取。
【思路5：sudo免加载终端问题】
思路4的局限性而不被采用。此时恍然大悟，求助于shell的输出重定向功能，看看为何不能执行，将返回值也查看下。
采用脚本System_root.sh ，内部将标准错误也一同输出到界面才发现问题：
sudo：抱歉，您必须拥有一个终端来执行 sudo
原来sudo执行时默认需要终端。
设置普通用户adz的sudo不使用默认值，在Default requiretty下再加一行Default：用户名 !requiretty：
目前采用此方案，尚未发现其他异常情况，如果存在，稍后更新
【思路6：其他思路】
为何mysql用户将mysqld.log写入操作系统路径，是否使用了sudo，它有没有参考性？
采取思路5是否有其他安全性需要处理，是否是最好的解决方式？
还有其他方式么？shell关于权限的处理刚接触，写的有些low了，有问题请指正。