2

I run a Weblogic installation on a Oracle Linux Server 7.8. An application in weblogic will write some files to a local directory as output. The application uses the Oracle Weblogic FileAdapter for it.

Setup of the directoy, with setgid:

[wesley@wesley from]$ ls -la
total 52
drwxrwsrwx 2 wesley group1 45056 Sep 14 16:15 .
drwxrwxrwx 3 wesley group1 4096 Sep 11 14:45 ..

When the application writes to the directory, you have following situation:

[wesley@wesley from]$ ls -la
total 816
drwxrwsrwx 2 wesley group1 45056 Sep 14 16:15 .
drwxrwxrwx 3 wesley group1 4096 Sep 11 14:45 ..
-rw-rw-r-- 1 oracle oinstall       57 Sep 14 15:05 20200914150523990.txt

So the setgid is being ignored and the file gets the group of the user of the process that writes the file, instead of the group of the directory.

Just touching a file there works as expected, the new file gets the right group:

[wesley@wesley from]$ sudo su oracle
[oracle@wesley from]$ touch abc
[oracle@wesley from]$ ll
total 0
-rw-rw-r-- 1 oracle group1 0 Sep 15 11:15 abc

Is it possible that an application can ignore the setgid or have I configured something wrong? Is there another way to force the group?

My next idea is to create a 'dirty' workarround by checken the group of the directory that is being written to and programmatically chown the file to the right group.

Update:

The output folder is located on an NFS mount. This is probably the cause. If I change the output to for example /tmp/output, the file does get the right group:

drwxrwsrwx    2 wesley    group1   4096 Sep 15 11:40 .
drwxrwxrwx. 245 root          root        16384 Sep 15 11:45 ..
-rw-rw----    1 oracle group1 824958 Sep 15 11:40 20200914150523990.txt

I'll update if we find a solution for it in the mount config or somewhere else.

Update 2:

It appears to not be an NFS issue. The first directory that fails was located in /vip/uri/from which is linked to a directory on an NFS. I've now made a directory under /vip/aaa/bbb, which is only locally and not on NFS, and it has the same issue. Files created in it don't get the group of the directory, but that of the user of the process writing the file.

stat of the working and the non-working directory:

  File: ‘/tmp/output’                                                       
  Size: 4096            Blocks: 8          IO Block: 4096   directory       
Device: fc00h/64512d    Inode: 67747909    Links: 2                         
Access: (2777/drwxrwsrwx)  Uid: (54322/wesley)   Gid: (54323/group1)
Access: 2020-09-15 17:39:59.014193471 +0200                                 
Modify: 2020-09-15 17:39:55.226794047 +0200                                 
Change: 2020-09-15 17:39:55.226794047 +0200                                 
 Birth: -                                                                   

  File: ‘/vip/aaa/bbb/’
  Size: 4096            Blocks: 8          IO Block: 32768  directory
Device: 2fh/47d Inode: 25954       Links: 2
Access: (2777/drwxrwsrwx)  Uid: (54322/wesley)   Gid: (54323/group1)
Access: 2020-09-15 17:31:19.613972000 +0200
Modify: 2020-09-15 17:30:31.016081000 +0200
Change: 2020-09-15 17:30:31.016081000 +0200
 Birth: -
Wesley De Keirsmaeker
  • 121
  • 3
  • 1
    I would have agreed with you if you'd confirmed it was NFS, as groups are not inherited (by default). Now though I'm not sure what you're seeing. – roaima Sep 15 '20 at 17:45
  • Still, the filesystem where the directory is located could have been mounted with the nosuid option? – A.B Sep 15 '20 at 20:20
  • @A.B does `nosuid` apply to more than executable files? I've never considered that – roaima Sep 15 '20 at 21:43
  • 2
    @roaima My previous comment was not tested. Test failed to prevent g+s from working, seems that was not that either. So I have no clue, it doesn't look that way. – A.B Sep 15 '20 at 21:51

0 Answers0