Re: Help solving the sysadm's nightmare
Good luck with your nightmare. if i would be in his case i would first not touch it and then slowly analyze EVERYTHING that is used on that system, and ask users how exactly they use it (i mean shared folders etc). Then i will step by step fix things to proper state, waiting for complaints after each step. if former "admin" did such things with permissions certainly he did many more stupid things. Certainly few things MUST be just done completely differently, not just different permissions. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Help solving the sysadm's nightmare
> 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- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Help solving the sysadm's nightmare
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 > > 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" > > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Help solving the sysadm's nightmare
> From: Wojciech Puchar > 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Help solving the sysadm's nightmare
On Thu, 19 Jul 2012 08:55:29 +0200, Erik Nørgaard wrote: > 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. For differentiating "files' nature", use "file " to identify if it's an executable, a script (which _may_ or _may not_ need +x attributes), or just some random text or binary file. Regarding access to files: You could first determine which programs are installed on that server and create a "testing bed" for them, e. g. using jails on a separate system. Then you can use tools like "lsof" to see what files are accessed, and in which matter (read, read/write). At this occassion, you can also examine what files have been installed to the system by this program's installer process, and what attributes they do _properly_ have. You can find information about _what_ is installed _where_ and _how_ in the package lists of each port. You can use them to compare currently installed stuff with how it should be. Regarding the OS, there's another helpful mechanism to investigate: Check out the files /etc/mtree which can be used to automatically compare the definitions with their current (probably malformed) real counterparts. Also see "man mtree" for details. > 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* I think the most safe method would be if you install a new server from scratch, install the PROGRAMS as needed, and then first copy the DATA with _default_ permissions and check if everything works. If you see that the new system works properly, you can easily switch over from the old system. If you have successfully done it, take the box to the "admin" who was "responsible" for it and drop it onto his head, so he can recover from "professionality". :-) > So, how can I > > - determine if files are actually unix executables or just plain files > (or windows executables)? As I said, file, mtree, pkg-plist. > - determine which users actually need read or write access to these files? Talk to the users (or better to their superiors, or anyone who is partially able to talk about what they're doing). User access should be separated and kept inside /home. There are very few cases where this method is not sufficient. Maybe you can find such a case and prepare a _proper_ solution to deal with it. If it's about what _programs_ need to access, check their documentation and configuration files. > the second is what I think is the most difficult, I need some lsof > daemon to log access... I think it's quite hard to determine requirements "in vivo". The more restricted your testing bed is, the more precise are your findings and therefor your answers. Have as few variables as possible. On a server actually running, using a malformed configuration and many altered settings (where you can't even properly tell _what_ has been altered!), testing will be quite hard. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Help solving the sysadm's nightmare
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, great. rm -rf /whatever would be even better! 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 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. 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)? man file - determine which users actually need read or write access to these files? depends on software lsof will not help you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Help solving the sysadm's nightmare
On 19/07/2012 07:55, Erik Nørgaard wrote: > So, how can I > > - determine if files are actually unix executables or just plain files > (or windows executables)? file(1) should help. > - determine which users actually need read or write access to these files? This is in most cases entirely a local policy matter. As in: you write up a proposal for how access control policy should be implemented and get it signed off by your managers before applying it. You'll need to present things with rational justifications: something along the lines of: Only the web-dev team and root (sys-admins) need write access to the doc-root www-data pseudo user (the UID apache runs as) needs read access to doc-root > the second is what I think is the most difficult, I need some lsof > daemon to log access... If you enable system accounting, I believe the detailed logs should show you all of the fileio broken down by user. Note that on a busy server, system accounting can generate a *large* amount of data, and it is likely to affect performance, so use with care. See lastcomm(1), sa(8), accton(8), acct(5) Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
