Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Jul 2012 02:59:40 -0500 (CDT)
From:      Robert Bonomi <bonomi@mail.r-bonomi.com>
To:        freebsd-questions@freebsd.org
Subject:   Re: Help solving the sysadm's nightmare
Message-ID:  <201207210759.q6L7xeka004536@mail.r-bonomi.com>
In-Reply-To: <alpine.BSF.2.00.1207191010200.7414@wojtek.tensor.gdynia.pl>

next in thread | previous in thread | raw e-mail | index | archive | help

> From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl>
> Date: Thu, 19 Jul 2012 10:12:05 +0200 (CEST)
> Subject: Re: Help solving the sysadm's nightmare
>

[[ sarcastic comment with no useful value removed ]]

> > 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.
> i can only help you with base system and ports permissions, and /var and
> /etc
>
> just look how it should be

Of gourse, setting system/ports permissins back to the way "it should be" 
WILL re-introduce the problems that were 'solved' by the prior administrator
changing permissiona as descrribed, resulting in UNACCEPTABLE interruption
of operations  -- quote: 
   "Everything is 'critical' there is no room for interruption of service."

> > 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.
>
> look at samba config to check as what user directories are accessed. set 
> it as such user and chmod 700 is enough.

While that "instruction" may have some relevance to _some_ situations, there
is *NO* guarantee that, say, multiple users in a given department of the 
business do _not_ require access to files in the 'user directory' of another
employee in that same department.  

While one can argue -- with some validity -- that things "should not" be
that way, one _cannot_ guarantee that such is not the case.  ESPECIALLY,
given the mind-set of the prior admin(s).  

Thus, changing permissions 'as directed' _does_ have a definite possibilit
of causing unacceptable interruption of critical services.

> > So, how can I
>
> > - determine which users actually need read or write access to these 
> > files?
>
> lsof will not help you.

Using lsof will *DEFINITELY* _help_ -- in identifying which applications 
access which files. lsof output will not be comprehensive/complete, because
a single lsof run only produces a snapshot of what currentl-running processes
have what files open at that time.  But it *DOES* provide a 'starting point',
a list of the files that the running applications are _proven_ to require
access to.  Changing permissions on those lsof-identified files, such that
the application in question does _not_ have access to it *WILL* break that
application.

Knowing what -not- to do -- because "doing that thing" _will_ break 
something --  is a _critical_ part of determining what =can= be done.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201207210759.q6L7xeka004536>