fmsedge & setgid in 3.5.3?

Hi,

on our staging platform I'm testing 3.5.3 instead of earlier 3.5.1. However, I've had a problem with fmsedge crashing straight on startup:

Edge (10636) is no longer active.
Edge (10636) _defaultRoot__edge1 experienced 1 failure!
Edge (10644) started, arguments : -edgeports ":1935" -coreports "localhost:19350" -conf "/opt/adobe/fms35/conf/Server.xml" -adaptor "_defaultRoot_" -name "_defaultRoot__edge1".

After some digging I found out that running as root (SERVER.PROCESS_UID=0) instead of my fms user, the problem went away. Further digging with some strace & the proper UID configured revealed this:

dev /opt/adobe/fms35# env LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:. strace ./fmsedge -edgeports ":1936" -coreports "localhost:19360" -conf "/opt/adobe/fms35/conf/Server.xml" -adaptor "_defaultRoot_" -name "_defaultRoot__edge1"

...
setuid32(511)                           = 0
capset(0x19980330, 0, {CAP_NET_BIND_SERVICE, CAP_NET_BIND_SERVICE, 0}) = 0
umask(017)                              = 022
umask(0)                                = 017
stat64("/opt/adobe/fms35/tmp", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
open("/opt/adobe/fms35/tmp/__FCS___shm_mtx", O_RDONLY|O_CREAT|O_LARGEFILE, 0666) = 12

...

stat64("/opt/adobe/fms35/conf/_defaultRoot_/Adaptor.xml", 0xffa42060) = -1 EACCES (Permission denied)
time(NULL)                              = 1272964592
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1892, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1892, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1892, ...}) = 0
socket(PF_FILE, SOCK_DGRAM, 0)          = 23
fcntl64(23, F_SETFD, FD_CLOEXEC)        = 0
connect(23, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0
send(23, "<131>May  4 11:16:32 Adaptor[127"..., 101, MSG_NOSIGNAL) = 101
gettimeofday({1272964592, 461875}, NULL) = 0
gettimeofday({1272964592, 461909}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1892, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1892, ...}) = 0
exit_group(100)                         = ?
dev /opt/adobe/fms35#

The file permission for the Adaptor.xml and conf directories above it is 640/750 and owned by root:fms.

So, based on the trace, it changes the UID properly, but still fails to open the Adaptor.xml. Basic test with "su fms -c 'cat /opt/adobe/fms35/conf/_defaultRoot_/Adaptor.xml'" gives me the file without any errors, so the user (when proper group has been set) CAN access the file.

From this I tried to change to more loose permissions, 755/644 on the configs, and after that change, it runs fine!

However, on my production 3.5.1 setups, aswell as my previous staging setup, we have the same file permissions. Anything changed in 3.5.1 regarding this?

Also, as noted in the output above, umask(017) is called (as configured), but straight after umask(0) is called, which results in all files in tmp beeing world writeable.. That doesnt look very good in my eyes, or is it intentional and harmless? Don't really know what is in/whit these files though, they seem empty.

Anyway, some input on the group problem is what I'm looking for mainly, thanks!