Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Jul 2012 19:00:48 -0600
From:      Modulok <>
To:        =?ISO-8859-1?Q?Erik_N=F8rgaard?= <>
Subject:   Re: Help solving the sysadm's nightmare
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
> I have inherited a problem that is no cause for envy, the previous
> administrators had no idea what they were doing, so problems with a
> permission denied would be solved by chown -R 777 /whatever! Needless to
> say, it's a mess, and ofcourse everything is "critical" there is no room
> for interruption of service.
> Now, I have no idea which processes actually require access to those
> files, what privileges these processes run with and which files are
> actually executable or just plain files.
> What I know is that lots of files are on samba shares and lots of files
> are used by uniface9 application, but I don't know much about uniface or
> if this is actually executed on the client or on the server.
> At this moment my project is to migrate servers with these permissions
> to new servers, but those who prepared the OS have maintained the
> permissions from the older version because it's easier than actually
> investigating or understanding what's going on and find a solution. *sigh*
> So, how can I
> - determine if files are actually unix executables or just plain files
> (or windows executables)?
> - determine which users actually need read or write access to these files?
> the second is what I think is the most difficult, I need some lsof
> daemon to log access...

Sounds like a disaster. You're going to have to weigh out the risks of not
doing anything and being compromised vs. trying to fix it and breaking
something. Depending on how involved you want to get, much coffee may be
required. Here's some thorny ideas:

First, take a snap shot of the file system if you can. That way if things get
screwed up you can always revert back to a previous state. That is, if the data
is read-only. (*Evil laugh*) If you can, experiment with this snapshot on a
test box. If not, keep reading...

You could call lsof from a script repeatedly (or use lsof's own reapeat
functionality) for several days/weeks/whatever. Then parse the output to
produce a list of unique files, how they're being accessed and by who. Get
familiar with the lsof manual page, especially the section about 'OUTPUT FOR
OTHER PROGRAMS'. You might insert your results into a file-backed sqlite
database that you can later interrogate from a script via SQL queries.

Also, crawl the file system and generate *another* sql table, or even flat file
of permissions as they currently exist. This way you can, in theory, always go
back to how things were, if needed. Of course, you'll need to write a script to
do this permission-restore business too.

>From there, crawl the first SQL table that you made of file access and set
permissions on those files appropriately. e.g: a file being accessed read/write
probably needs to be set read/write. This will be a job for another script. You
can also build a table of file permissions for known files e.g:
/etc/master.passwd should be root read/write and so on. You can build up your
initial database of known permissions by parsing a clean install with the same
scripts you just wrote. Also see the 'file' command to help identify

Obviously, you're going to have to be very careful. (Again, have the backup and
preferably the script that restores file permissions to what they were, first.)
Sounds like a job for python ;)

Finally, remember to *thoroughly* test your scripts on an dummy system first!
Perhaps a virtual box install where you don't have to worry about screwing
things up. The last thing you want, is to get fired for trying to fix someone
else's mistake. Tread carefully. Talk to the boss/owner/client about the pros,
cons and risks before taking on such a project.

Good luck with your nightmare.

Want to link to this message? Use this URL: <>