Help figuring out a directory permission change problem

[stoveboltgeek]

This may not be the right group for this, since it's not really a shell scripting problem. If it isn't, I apologize.

I manage a CentOS server, and it has the following file structure: /var/ubbthreads/upload
The upload directory is where graphics attachments go when people post them in the forum.

Every once in a while, the permissions get changed on the upload directory from 755 to 555, which breaks all the images since apache can't enter the directory.

In an attempt to determine the cause, I enabled auditing. But I've never done this before and have no idea what I'm looking at. Every time a new image is copied to the uploads folder, audit see that. So, I ran the following command to eliminate all the images from the return.

grep upload /var/log/audit/audit.log | egrep -v "jpg|jpeg|png"

This is what I got back:

type=PATH msg=audit(1683913262.093:1042): item=0 name="/var/ubbthreads/uploads" inode=1074941969 dev=09:7d mode=040666 ouid=48 ogid=1004 rdev=00:00 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0


type=PATH msg=audit(1683913262.093:1043): item=0 name="/var/ubbthreads/uploads" inode=1074941969 dev=09:7d mode=040666 ouid=48 ogid=1004 rdev=00:00 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0


type=PATH msg=audit(1683913262.093:1044): item=0 name="/var/ubbthreads/uploads" inode=1074941969 dev=09:7d mode=040666 ouid=48 ogid=1004 rdev=00:00 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0


type=PATH msg=audit(1683913298.346:1109): item=0 name="/var/ubbthreads/uploads/" inode=1074941969 dev=09:7d mode=040666 ouid=48 ogid=1004 rdev=00:00 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0

ouid 48 is apache ogid 1004 is editor, which is the group for the owners' account. Does mode 040666 mean the perms were changed to 666? And what account changed them? (It's frustrating that audit doesn't put a date/timestamp on these log entries. I need to read the man page and see if I need to make a config change.)

If it helps, here's the results of aureport

Summary Report
======================
Range of time in logs: 12/31/1969 19:00:00.000 - 05/12/2023 14:18:33.741
Selected time for report: 12/31/1969 19:00:00 - 05/12/2023 14:18:33.741
Number of changes in configuration: 3
Number of changes to accounts, groups, or roles: 0
Number of logins: 1
Number of failed logins: 775
Number of authentications: 19
Number of failed authentications: 2820
Number of users: 3
Number of terminals: 8
Number of host names: 67
Number of executables: 11
Number of commands: 7
Number of files: 9016
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 35729
Number of anomaly events: 1
Number of responses to anomaly events: 0
Number of crypto events: 7831
Number of integrity events: 0
Number of virt events: 0
Number of keys: 1
Number of process IDs: 1719
Number of events: 47658

 

[alexcray]

You're right, this isn't a shell scripting problem specifically, but it's definitely a Linux administration issue and you're on the right track! Here's how to analyze the audit logs and potentially identify the culprit changing the permissions.