[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
