Help solving the sysadm's nightmare

[Erich Dollansky]

Hi,

what or who stops you from making a copy of the machine and start testing there?

This is the only valid option if you do not want to interrupt a running server.

Erich

On Saturday 21 July 2012 14:59:40 Robert Bonomi wrote:
> 
> > From: Wojciech Puchar <wojtek at 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.
> 
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> 
>