So, I just got a notice from KDE complaining about my / partition to be 100% full.
After some digging I found that one of the main culprits was this file /var/log/security/sgid.today:

/var/log/security:
total 3676305
-rw-r----- 1 root root 2011881472 Dec 6 20:52 sgid.today
-rw-r----- 1 root root 1098309632 Dec 7 10:00 unowned_user.today

I do not see any entry on logrotate to deal with this file.. I do not have a clue on what process is using it or how can I shrink it..
simply use vi to delete entries manually?

I'm using Mandriva 2007.1 if that makes any difference...

Some help will be appreciated.

Fercho

The logs in /avr/log/security are the result of the msec security checks. I think something is seriously wrong if you have big files there (1-2GB). Eitehr teh files have become corrupt, or your system has been corrupted. The only exception I can imagine is if you have just done a system update (2007.0 --> 2007.1); this would create big differences, but even that would probably only give you files of at most a few 100K. The msec script (/usr/sbin/msec) will take care of 'rotating' these files (keeps those of yesterday and today only). My suggestion is to inspect other logs (/var/log/messages) for abnormal messages and in general verify that your system is yours and truely working.

afaik sgid-today should be overwritten everytime msec makes its security-check, therefore such a large file is definitely not normal.

Have a look in the file it will have all the files listed in your system which are in its idea the wrong permission.

Some are probably world readable. If you dont want that change them and the file will be alot smaller

You can also go into the security section under MCC and change the levels for the each item individually.

You probably have bigger problems though do a
du -sb * | sort -n

This will give you a sorted list of how much space each directory is taking up.

Yesterday i did an upgrade and had a few core files created very quickly I had no space.

if you just want to make it empty quickly do this command

tail /var/log/security/sgid.today > /var/log/security/sgid.today

then you will only have the last ten lines in the file and the space will be instantly given back.. But you do have a problem to look at.

You would appear to have a problem, and, rather than deleting/rotating your log I would be inclined to find the cause of such a large file. The contents of the file should give you clues. Remember theses logfiles are there for reference, so don't just discard that reference, find the cause first.

Thanks michaelcole.

I have found that most of the files listed in the log are located in a samba (cifs) mount. I can not change the permissions for those files! Maybe it is the cifs comand I'm using? I need to be able to edit files in those mount so I mount them using a line in fstab like this:

//server/mount_point /home/feramos/mounted cifs uid=myuser,credentials=/etc/samba/ccorp,rw,domain=mydomain,setuids 0 0

Suggestions ?

Fercho

You should exclude that mount from msec security checking -- it doesn't make sense to that (unless you use that as a source of programs, but even then I guess that the administrator of that share will do the security checking).

How would you go about that? What I did was to go to the GUI and added rules to give complete permissions to those files.
I'm pretty sure that it would be more efficient to edit a configuration file for msec, but I do not know what should I be looking for...

Fercho

It turns out this is well hidden, but I think I have nailed it (but cannot check).

The file /usr/share/msec/security.sh governs the daily security check (there is another file for the hourly check). I think the area to modify starts at line 74:



My understanding is that this excludes a list of mounts from scanning, provided they match on the filesystem (line 77, starting with TYPE_FILTER and isolated in above listing; note it excludes smbfs, but doesn't exclude cifs) AND/OR mount-point (/mnt) -- (Somebody who knows awk pls step in to confirm this). Your setup matches neither, so is included for scanning.

I suggest you add |cifs to line 77 (inside the quotes) and test again; if it still fails then ensure your share is mounted in /mnt and try again. If it still fails then I am wrong.

That was it! Thanks a lot pindakoe.

Now, being CIFS the prefered way to access a samba resource, I think this fix should be added to the distro. Who should I contact about that?