Date: Mon, 16 Jun 2008 05:52:40 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: search path for config file On Mon, Jun 16, 2008 at 12:32:55PM +1200, Russell Fulton wrote: > I need some clarification about this. The CONFIG file says: > > <quote> > This file is searched for in private John's "home directory" and, if > not found in the private directory and John is installed system-wide, > also in John's system-wide shared data files directory. > </quote> > > but I find this confusing. Yes, I felt that it would be confusing, but I kind of could not avoid that while leaving the documentation sufficiently generic - applying to all builds of JtR on all platforms - and not too verbose. However, now that you brought this issue up, I think I should have included this verbosity somewhere - I am just not sure where exactly. There are two main cases: 1. Non-system-wide build (params.h has JOHN_SYSTEMWIDE at 0, which is the default in official source code distributions, as well as in official Win32 and DOS builds). In this case, John's "home directory" is the current directory (usually, it will be the "run" directory). 2. System-wide build (params.h has JOHN_SYSTEMWIDE at 1, which is the default in JtR Pro, as well as in some other pre-packaged distributions of John - e.g., in some Linux distributions and *BSD ports). Also, JOHN_SYSTEMWIDE may be set to 1 from the "make" command-line, which is in fact the preferred approach for packages based on the pristine source code for John. In this case, John's "home directory" is ~/.john (that is, directory named ".john" in the current Unix user's home directory). Additionally, a shared data files directory exists, by default it is /usr/share/john as specified via JOHN_SYSTEMWIDE_HOME in params.h, but some packages may alter it. When loading a file such as john.conf or all.chr, John looks for it in ~/.john first, and if not found, then it looks in the shared directory. This allows users on a system to override files that are installed system-wide (in the shared directory) by placing alternate versions into their private ~/.john directories. This also allows a system administrator to not abuse root powers merely to modify john.conf - instead, he or she would copy the file to ~/.john and modify the copy. > I have found that john will find config files in the current directory. This means that you're using a non-system-wide build, which is fine. > I have tried setting the environment variable JOHN but > this does not seem to have any effect. Correct. John does not use environment variables. I understand that the "$JOHN" notation in john.conf might be a bit confusing in this respect. Should I replace the "$" with another character (what character) or should I enhance the code to actually check for environment variable of this name first or is it better to leave everything as-is but improve the documentation? > On a side issue I am about to get my grubby mitts on an "IronKey > Enterprise" encrypted flash drive and intend to install john on the > secured portion of the drive and keep the password files and pot etc. > on the normal file section. That way I should have all the sensitive > stuff in one very secure place. Would you also disable swap on the systems where you do any processing of the sensitive files? Note that you would need to not re-enable the swap until you power-off and wait at least a few minutes before powering back on. ;-) (The power-on memory test might be bypassed or it might be non-destructive - it was never meant as a security measure.) That's the paranoia; in practice, there are many "natural" mitigating factors, which make sensitive data leaks via swap not too likely (especially on Linux, which makes relatively little use of swap) - but I do disable swap on my computers before mounting encrypted filesystems, and I don't re-enable it until I reboot. > If anyone is interested in how this goes drop me a note I suggest that you simply post a summary to the list. Thanks, Alexander -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ