multiple users - custom session file location?

[Adriaantje]

Hi all,

I'm trying to set up a cracking machine, which will be used by multiple users, who might want to run multiple jobs.
Normally this all goes perfectly using sessions.

Now, I really prefer not giving all users write access to the hashcat directory.
Unfortunately, hashcat seems to explicitly want to place these sessions in its own directory, causing users to get permission errors and hashcat quitting.

Is it possible to provide a custom location for the sessions (and any other files that may need to be created) ?

I'm running hashcat v5.1.0

[philsmd]

Well, you didn't really explain how you intend to install/use hashcat and also how you manage the access to GPU/CPU OpenCL resources.

I think the main problem with multi-user system and hashcat is the resource sharing. Are those accounts logged in at the same time or is it guaranteed that only 1 user runs hashcat at any time ?

Back to the main problem/question, I think you used "make install" to install hashcat... but you can also just put the hashcat download into every users /home/[user]/software/hashcat/ (or similar) folder and therefore each and every user has their own hashcat folder and there won't be any conflct with permissions and restore/log/potfile etc

Does this solution work for you ?

BTW: as you might already know, some files can be choosen when hashcat is launched, like --restore-file-path , --potfile-path and --outfile etc

[Adriaantje]

Every user having their own hashcat is the workaround we use now, but this is not our preferred solution, for 2 reasons:

1. It requires multiple users to keep their hashcat up-to-date, and I don't expect that to go too well.
2. We currently have a bash script that people use, which does all kinds of masks and other smart tricks (don't know the specifics, it's not mine), running a bunch of hashcat commands in sequence. This would also require everyone having their own version of this script, which will have the same problem as 1.


Hashcat is installed by downloading and extracting the zip, and putting it in /opt/

To explain our workflow some more, everyone has their own user on the system, and they might log in at the same time. only 1 user running hashcat at the same time is exactly what we're trying to avoid.
These users login, start a screen session, run the script, and basically wait for results.


I hope this helps explain my situation, and thanks in advance for the help!

[philsmd]

I don't think this is a good idea to share GPU/CPU devices like this. everyone will be experiencing reduced performance if somebody else has an attack running at the same time.

I also do not understand what files should be available to the different users, but I think that --session, --restore-file-path, --potfile-path and --outfile options could be very handy for you. You could just write your own wrapper that the single users can run, instead of launching hashcat directly and every user has some [username] within their --session name and also paths with usernames for the different users.

Of course it's a little bit work to write this wrapper, but at the end a small shell script should do it quite well.

Your situation is very unusual that users shouldn't manage their own software and should run hashcat at the same time etc. I'm not sure if this is a good idea, but maybe you have some good reason to do this that I can't think about right now.

[undeath]

@philsmd: I think the main problem here is hashcat writing the restore files to the directory of the executable, which the users do not have permission to, since that is managed by the system administrator. There should be a way to relocate the path of restore files.

all your users need to use should be the options mentioned by philsmd, possibly with the exception of hashcat.log(?)

edit after takling to philsmd on irc: all you need to do is install hashcat using "make install". That will use ~/.hashcat for all users

[Adriaantje]

the "make install" method sounds absolutely perfect for what I need!

I'll see if I can get this going, and report back with the result.

[Adriaantje]

Delayed report, but a report nonetheless

This installation method is indeed exactly what I need.
Using --session, everything is placed in the user's home folder, and multiple jobs can be run.

Thanks for this pro-tip!