MQ7.5以后的权限问题解决

MQ7.5以后权限是个问题,目前我也没有什么特别好的解决办法,把认证通道关闭就可以正常使用。

下面是IBM 官方的解释,可惜我没调通,望高人指点!

疑问

您使用MQ 7.1或者7.5创建了一个新的队列管理器。然后,您尝试使用管理员账户从客户端访问该队列管理器。您得到返回值为“2035 MQRC_NOT_AUTHORIZED”的错误。

为什么在MQ 6.x或者7.0.x中,MQ管理员可以远程访问队列管理器,而不会产生任何错误?

原因

当您使用MQ 7.1或者MQ 7.5创建一个新的队列管理器的时候,MQ 7.1新引入的通道认证记录功能就默认被启用。您可以使用下列命令来查看该设置。

$ runmqsc QmgrNameDISPLAY QMGR CHLAUTHAMQ8408: Display Queue Manager details.QMNAME(TEST01) CHLAUTH(ENABLED)

在默认情况下,创建队列管理器会产生下列三条通道认证记录:$ runmqsc QmgrName

DISPLAY CHLAUTH(*)AMQ8878: Display channel authentication record details.CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)ADDRESS(*) USERSRC(CHANNEL)AMQ8878: Display channel authentication record details.CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)ADDRESS(*) USERSRC(NOACCESS)AMQ8878: Display channel authentication record details.CHLAUTH(*) TYPE(BLOCKUSER)USERLIST(*MQADMIN)

其中,最后一条记录拦截所有以MQ管理员身份的远程通道访问。非管理员用户在赋予一定权限的情况下仍然可以远程连接队列管理器,而管理员用户和匿名用户被禁止连接。这意味着在新版本MQ中,队列管理器更加安全。当然,这就需要显式定义管理权限。另外,需要注意以下几点:

a)如果升级一个队列管理器到MQ 7.1,那么这个新功能默认是关闭的。

$ runmqsc QmgrNameDISPLAY QMGR CHLAUTHAMQ8408: Display Queue Manager details.QMNAME(TEST01) CHLAUTH(DISABLED)

当然,您可以使用如下命令开启该功能。

ALTER QMGR CHLAUTH(ENABLED)

b) 如果您使用MQ资源管理器远程访问新创建的MQ 7.1队列管理器,会得到如下错误:

关闭该对话框后,弹出另外一个对话框:

该错误表明MQ资源管理器不能远程连接到队列管理器。

c) 从错误日志中,可以看到错误AMQ9776或者9777,然后还有AMQ9999。

c.1) AMQ9776: Channel was blocked by userid

c.2) AMQ9777: Channel was blocked

c.3) AMQ9999: Channel ‘SYSTEM.ADMIN.SVRCONN‘ to host ‘x (9.49.x.x)‘ ended abnormally.

以上错误表明远程连接符合某条通道认证记录,从而被拦截。

答案

1) 如果在生产环境中,建议使用非管理员账户访问队列管理器,而不是管理员账户。

2) 如果您一定要使用MQ管理员账户远程访问队列管理器,您可以采取以下措施。

2.a) 您可以参考下面的资料,添加两条通道认证记录。

http://www.websphereusergroup.org/go/article/view/251913/whats_new_in_websphere_mq_v7.1_security

第10页: 用户ID拦截

第一条记录拦截所有的管理员用户及“nobody”用户。

$ runmqsc QmgrName

SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST(‘nobody‘,‘*MQADMIN‘)

第二条记录对管理员账户开放了SYSTEM.ADMIN通道的访问,只拦截“nobody”用户。这里,MQ假设其它的通道认证记录或者用户安全出口可以完成对管理员账户的认证。

SET CHLAUTH(SYSTEM.ADMIN.*) TYPE(BLOCKUSER) USERLIST(‘nobody‘)同样,上面的记录适用于SYSTEM.ADMIN.SVRCONN通道,可以被MQ资源管理器使用。

如果您使用其它的自定义的通道,例如MY.ADMIN.SVRCONN。您需要定义如下记录:

SET CHLAUTH(MY.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)SET CHLAUTH(MY.ADMIN.SVRCONN) TYPE(BLOCKUSER) USERLIST(‘nobody‘)

注意:我们不建议用户连接SYSTEM.DEF.*通道。这些系统定义的通道是定义其它用户通道的模板。不建议用户使用SYSTEM.DEF.*和SYSTEM.AUTO.*通道。

2.b)该方法是2.a)的一个演变,但是只允许管理员账户从特定主机连接。

第一条规则拦截“nobody”用户。

SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(BLOCKUSER) USERLIST(‘nobody‘)

第二条规则删除所有对SYSTEM.ADMIN.SVRCONN通道的访问。

SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) ACTION(REMOVE)

第三条规则添加一个访问入口。

SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(9.27.4x.7y) USERSRC(CHANNEL)

2.c) 停止通道认证功能。

ALTER QMGR CHLAUTH(DISABLED)

警告:对于生产环境,停止该功能是不推荐的。因为停止该功能,将导致队列管理器接受所有的管理权限的连接,这就需要用户付出更大的努力去管理这些连接。因此,出于安全考虑,请保持通道认证记录功能启用。同时,使用MQ 7.1的其它功能完成连接认证。

时间: 2024-08-14 01:10:09

MQ7.5以后的权限问题解决的相关文章

mac下修改mysql-root密码-各种权限问题解决

官方资料:http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html#resetting-permissions-unix 还有一个值得参考的mysql安装,与python-mysql安装博客http://hearrain.com/2011/01/498 据官方文档说, For example, if you run the server using the mysql login account, you should l

virtualbox共享文件夹无访问权限问题解决方法

早就困扰了,这次新装虚拟机又碰到了,记录下来. 这篇文章主要介绍了virtualbox共享文件夹无访问权限问题解决方法,造成这个问题的原因是不跟virtualbox在同一个用户组,所以加入同个组即可解决这个问题,需要的朋友可以参考下virtualbox的共享文件夹一般都挂载在/media下面,用ll查看会发现文件夹的所有者是root,所有组是vboxsf,所以文件管理去无法访问是正常的,解决方法是把你自己加入到vboxsf组里面. 复制代码代码如下:sudo usermod -a -G vbox

【转载】在 Mac OS X El Capitan 文件权限问题解决方法 (以安装 IPython 和 XtraFinder为例)

转载者注:升级了EI Captitan后,Mac系统对很多文件的管理权限直接进行了锁死,root无法修改,目前据我所知受影响的包括vim的配置文件,Python的一些文件(Python转exe程序的工具也会出问题),本篇文章提供了一个很好的思路,我也是在安装ipython时搜到这篇文章的. 亲测原文内容可用,但是貌似还少了一个步骤,因为我完全按照原文内容安装后ipython找不到,还要在pip安装并更新后运行easy_install,这样的话可以将ipython加入/usr/bin/的路径中.

实现hive proxy5-数据目录权限问题解决

hive创建目录时相关的几个hdfs中的类: org.apache.hadoop.hdfs.DistributedFileSystem,FileSystem 的具体实现类 org.apache.hadoop.hdfs.DFSClient,client操作hdfs文件系统的类 org.apache.hadoop.fs.permission.FsPermission 文件权限相关类,主要的方法有getUMask和applyUMask方法 org.apache.hadoop.hdfs.Distribu

实现hive proxy4-scratch目录权限问题解决

hive在hdfs中的job中间文件是根据当前登陆用户产生的,其默认值为/tmp/hive-${user.name},这就导致实现proxy的功能时会遇到临时文件的权限问题,比如在实现了proxy功能后,以超级用户hdfs proxy到普通用户user时,在hdfs中的临时文件在/tmp/hive-user目录中,而目录的属主是hdfs,这时再以普通用户user运行job时,对这个目录就会有权限问题,下面说下这里proxy的实现和解决权限问题的方法:1.实现proxy功能更改org.apache

实现hive proxy3-日志目录权限问题解决

使用proxy之后,目录名为proxy之后的用户名目录,但是生成的文件属主是当前登陆用户,导致不能正常写入,日志目录的创建在org.apache.hadoop.hive.ql.history.HiveHistoryImpl类中,更改后的构造方法(增加了proxy之后的代码): public HiveHistoryImpl(SessionState ss) {   try {     console = new LogHelper(LOG);     if(ss.getConf().getBool

备忘 Linux下非root用户实现crontab+rsync数据同步权限问题解决办法

如果在命令行手动执行rsync命令可以正常同步数据,但是在crontab定时任务里提示权限失败. 遇到这种情况,可以在rysnc命令里指定用ssh安全隧道方式的同时参数指定使用可以免密码登录对方机器的认证密钥文件. 1,创建一个新的密钥 ssh-keygen -t rsa 2,将密钥添加到对方主机信任中,实现免密码ssh登录 ssh-copy-id -i[密钥文件] [非root用户名]@[对方主机] 3,再在crontab里跑rsync试试 rsync -e'ssh -p22 -i[你的密钥文

Ubuntu下使用git clone 的权限问题解决方法

问题1.sign_and_send_pubkey: signing failed: agent refused operation,执行如下语句: 1 eval "$(ssh-agent -s)" 2 ssh-add 问题2.若出现如下提示: 则对应修改自己的私钥文件权限即可. 1 chmod 700 parkcloud-new.pem 然后重新执行git clone 远程仓库地址即可. 原文地址:https://www.cnblogs.com/hsl-shiliang/p/91730

ubuntu usb权限问题解决

在/etc/udev/rules.d/ 创建51-android.rules SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0666" SUBSYSTEM=="USB", ATTR{idVendor}=="15ba", MODE="0666"