Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 8 - Error: does not exist, please create this directory #353

Closed
ghost opened this issue Jan 10, 2021 · 15 comments
Closed

Version 8 - Error: does not exist, please create this directory #353

ghost opened this issue Jan 10, 2021 · 15 comments
Labels
bug Known bug in the code.

Comments

@ghost
Copy link

ghost commented Jan 10, 2021

I'm on Windows. The error is happening in a new routine that was added for 8.0

Use of uninitialized value $dir_check in concatenation (.) or string at d:\winids\pulledpork\pulledpork.pl line 1720.
Error:  does not exist, please create this directory
at d:\winids\pulledpork\pulledpork.pl line 1720.
        main::check_file_dir("d:\\winids\\snort\\rules\\winids.rules") called at d:\winids\pulledpork\pulledpork.pl line 1872

The routine where the error is happening:

## Verify if directories or files actually exist
sub check_file_dir {
    my ($filedir_input) = @_;
    my ($dir_check, $file_check) = ($filedir_input =~ /(^.*)\/(.*)$/);
    if (!-d $dir_check && !-w $file_check) {
        croak
            "Error: $dir_check does not exist, please create this directory\n";
        exit(1);
    }
}

I have removed the winids.rules from my pulledpork.conf file thinking PP was just looking for a path, but no change in the error except it removed the winids.rules from the error message.

# What path you want the .rules file containing all of the processed 
# rules? (this value has changed as of 0.4.0, previously we copied 
# all of the rules, now we are creating a single large rules file
# but still keeping a separate file for your so_rules!
rule_path=d:\winids\snort\rules\winids.rules

The path does exist.

C:\Windows\system32>tree /F d:\winids\snort\rules
Folder PATH listing for volume Storage
Volume serial number is BAC6-CCE2
D:\WINIDS\SNORT\RULES
    black_list.rules
    experimental.rules
    local.rules
    white_list.rules
    winids.rules

No subfolders exist
@shirkdog shirkdog added the bug Known bug in the code. label Jan 10, 2021
@shirkdog
Copy link
Owner

Stupid Windows :) I will get this fixed up to work with various paths.

shirkdog added a commit that referenced this issue Jan 11, 2021
@shirkdog
Copy link
Owner

Try the latest pulledpork.pl and let me know if that works for you on windows.

@ghost
Copy link
Author

ghost commented Jan 11, 2021 via email

@shirkdog
Copy link
Owner

shirkdog commented Jan 11, 2021

The "" is escaped to be "\" in the statement, so what I have added should fix it. I just do not have windows setup with ActiveState at the moment to test. You need to keep the file name as it is verifying the path and the filename exist.

@ghost
Copy link
Author

ghost commented Jan 11, 2021 via email

shirkdog added a commit that referenced this issue Jan 11, 2021
@shirkdog
Copy link
Owner

Weird thing to appear, may be windows specific for the PCRE...try the latest latest.

@ghost
Copy link
Author

ghost commented Jan 11, 2021 via email

@shirkdog
Copy link
Owner

shirkdog commented Jan 11, 2021

Can you try two variations of the rule_path in your pulledpork.conf?

rule_path=d:\\winids\\snort\\rules\\winids.rules
and
rule_path=d:/winids/snort/rules/winids.rules

If the top one works, than it was the slashes causing the filepath in the PCRE to be interpreted as UNICODE.

If the bottom one works, that is going to be the recommended path, and I will make note in the documentation.

@ghost
Copy link
Author

ghost commented Jan 11, 2021 via email

@ghost
Copy link
Author

ghost commented Jan 12, 2021 via email

@shirkdog
Copy link
Owner

shirkdog commented Jan 12, 2021

Hmm...can you move your directory to d:\winids\script instead of d:\winids\pulledpork.

If that works, its an issue where your path running on Windows must be escaped...that will be a different fix and it will be a different bug.

@ghost
Copy link
Author

ghost commented Jan 12, 2021 via email

@shirkdog
Copy link
Owner

Correct, as a test. You opened this issue due to a bug in the check_file_dir subroutine...I have fixed that issue. Now it appears that on Windows the path is being interpreted as \p{} for unicode within the PCRE. If this test works, I will open another bug and close this out.

@ghost
Copy link
Author

ghost commented Jan 12, 2021 via email

@shirkdog
Copy link
Owner

Great, so the initial bug is fixed, this is a path issue with Windows paths. I will close this and open another issue to track.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Known bug in the code.
Projects
None yet
Development

No branches or pull requests

1 participant