From owner-freebsd-questions@FreeBSD.ORG Sun Jul 22 01:00:49 2012 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90DCA106564A for ; Sun, 22 Jul 2012 01:00:49 +0000 (UTC) (envelope-from modulok@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45F7B8FC08 for ; Sun, 22 Jul 2012 01:00:49 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so2113236vcb.13 for ; Sat, 21 Jul 2012 18:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lS2vHdgT1OKtfbWZvTxQ5yjodJVNyY05hmhF6+/w9jI=; b=IzivdkWhHyUWHnhGQgNvG28hgVgI4c7lMy+zjalsTySehZSkqiLRhz1auF1rlrYPB3 9CkTIOcX/7aU9X3FRShJlAXYht5knZsi3jkwII8jqX0m1li+i4zuRTk7sayQ3TO/nvZb tVYsKL36aDMScKWNkqftaK+4ELPlTzM/lXVBRCCfaVq8AQjlYZNjCfxawBridW/3pqBq i6myXAVxD4dxXFvCywDYliilzDYcL/+Z5iLwQsdzTOYNT0LD37G3XbpRTa7zGPkwqWlt JlOG3IGTAeFPmOtTMJl2SPjd9OGFJh80hZf1k40IrN0xo+sZ8uohI6919NAZFfgSp7mU 9Nww== MIME-Version: 1.0 Received: by 10.52.179.129 with SMTP id dg1mr7399791vdc.71.1342918848338; Sat, 21 Jul 2012 18:00:48 -0700 (PDT) Received: by 10.52.184.201 with HTTP; Sat, 21 Jul 2012 18:00:48 -0700 (PDT) In-Reply-To: <5007AF61.4090207@locolomo.org> References: <5007AF61.4090207@locolomo.org> Date: Sat, 21 Jul 2012 19:00:48 -0600 Message-ID: From: Modulok To: =?ISO-8859-1?Q?Erik_N=F8rgaard?= Content-Type: text/plain; charset=ISO-8859-1 Cc: questions@freebsd.org Subject: Re: Help solving the sysadm's nightmare X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 01:00:49 -0000 > 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 executables. 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. -Modulok-