fercho Posted December 7, 2007 Report Share Posted December 7, 2007 (edited) 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 Edited December 7, 2007 by fercho Quote Link to comment Share on other sites More sharing options...
pindakoe Posted December 7, 2007 Report Share Posted December 7, 2007 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. Quote Link to comment Share on other sites More sharing options...
lavaeolus Posted December 13, 2007 Report Share Posted December 13, 2007 afaik sgid-today should be overwritten everytime msec makes its security-check, therefore such a large file is definitely not normal. Quote Link to comment Share on other sites More sharing options...
michaelcole Posted December 13, 2007 Report Share Posted December 13, 2007 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. Quote Link to comment Share on other sites More sharing options...
SilverSurfer60 Posted December 13, 2007 Report Share Posted December 13, 2007 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. Quote Link to comment Share on other sites More sharing options...
fercho Posted December 13, 2007 Author Report Share Posted December 13, 2007 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 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 Quote Link to comment Share on other sites More sharing options...
pindakoe Posted December 14, 2007 Report Share Posted December 14, 2007 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). Quote Link to comment Share on other sites More sharing options...
fercho Posted December 17, 2007 Author Report Share Posted December 17, 2007 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... :unsure: Fercho Quote Link to comment Share on other sites More sharing options...
pindakoe Posted December 17, 2007 Report Share Posted December 17, 2007 (edited) 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: # Modified filters coming from debian security scripts. # rootfs is not listed among excluded types, because # / is mounted twice, and filtering it would mess with excluded dir list TYPE_FILTER='(devpts|sysfs|usbfs|tmpfs|binfmt_misc|auto|proc|msdos|fat|vfat|iso9660|ncpfs| smbfs|hfs|nfs|afs|coda)' MOUNTPOINT_FILTER='^\/mnt' DIR=`awk '$3 !~ /'$TYPE_FILTER'/ && $2 !~ /'$MOUNTPOINT_FILTER'/ \ {print $2}' /proc/mounts | uniq` PRINT="%h/%f\n" EXCLUDEDIR=`awk '$3 ~ /'$TYPE_FILTER'/ || $2 ~ /'$MOUNTPOINT_FILTER'/ \ {print $2}' /proc/mounts | uniq` export EXCLUDEDIR 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. Edited December 17, 2007 by pindakoe Quote Link to comment Share on other sites More sharing options...
fercho Posted January 28, 2008 Author Report Share Posted January 28, 2008 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: ... 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? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.