Project

General

Profile

Actions

Bug #3219

closed

permission of data dir should be checked before operations

Added by Victor Julien about 5 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

When running with insufficient permissions, the default updating is kind of ok:

$ ./bin/suricata-update --suricata-conf ../suricata/suricata.yaml --suricata ../suricata/src/suricata
5/10/2019 -- 08:08:06 - <Info> -- Using data-directory /var/lib/suricata.
5/10/2019 -- 08:08:06 - <Info> -- Using /etc/suricata/rules for Suricata provided rules.
5/10/2019 -- 08:08:06 - <Info> -- Found Suricata version 5.0.0-dev at ../suricata/src/suricata.
5/10/2019 -- 08:08:06 - <Info> -- Loading ../suricata/suricata.yaml
5/10/2019 -- 08:08:06 - <Info> -- Disabling rules with proto modbus
5/10/2019 -- 08:08:06 - <Info> -- Disabling rules with proto enip
5/10/2019 -- 08:08:06 - <Info> -- Disabling rules with proto dnp3
5/10/2019 -- 08:08:06 - <Warning> -- Source index is older than 2 weeks. Please update with suricata-update update-sources.
5/10/2019 -- 08:08:06 - <Info> -- Fetching https://rules.emergingthreats.net/open/suricata-5.0.0/emerging.rules.tar.gz.
 100% - 2461714/2461714
5/10/2019 -- 08:08:12 - <Error> -- Failed to copy file: [Errno 13] Permission denied: u'/var/lib/suricata/update/cache/1168f1cf2d4676c8d507bbb6ea3b2078-emerging.rules.tar.gz'

Although I would have expected an error sooner, like right after
5/10/2019 -- 08:08:06 - <Info> -- Using data-directory /var/lib/suricata.

But when doing the update-sources command things get more ugly:

$ ./bin/suricata-update --suricata-conf ../suricata/suricata.yaml --suricata ../suricata/src/suricata update-sources
5/10/2019 -- 08:08:34 - <Info> -- Using data-directory /var/lib/suricata.
5/10/2019 -- 08:08:34 - <Info> -- Using /etc/suricata/rules for Suricata provided rules.
5/10/2019 -- 08:08:34 - <Info> -- Found Suricata version 5.0.0-dev at ../suricata/src/suricata.
5/10/2019 -- 08:08:34 - <Info> -- Downloading https://www.openinfosecfoundation.org/rules/index.yaml
Traceback (most recent call last):
  File "./bin/suricata-update", line 33, in <module>
    sys.exit(main.main())
  File "/home/victor/dev/suricata-update/suricata/update/main.py", line 1512, in main
    sys.exit(_main())
  File "/home/victor/dev/suricata-update/suricata/update/main.py", line 1285, in _main
    return args.func()
  File "/home/victor/dev/suricata-update/suricata/update/commands/updatesources.py", line 50, in update_sources
    with open(local_index_filename, "wb") as outobj:
IOError: [Errno 13] Permission denied: u'/var/lib/suricata/update/cache/index.yaml'

Observed on 1.1.0rc1.

Actions #1

Updated by Shivani Bhardwaj about 5 years ago

  • Status changed from New to Assigned
  • Target version set to 1.1.0
Actions #2

Updated by Shivani Bhardwaj about 5 years ago

Victor Julien wrote:

When running with insufficient permissions, the default updating is kind of ok:
[...]
Although I would have expected an error sooner, like right after

I think that if we have to follow EAFP (https://docs.python.org/3/glossary.html#term-eafp) this is probably at the right place as we're not writing the directory when we're determining its path during configuration. `os` module methods do not cover a lot of cases so checking for write access may not be fool-proof.

Let me know if you have other opinion.

But when doing the update-sources command things get more ugly:
[...]

Observed on 1.1.0rc1.

Actions #3

Updated by Jason Ish about 5 years ago

  • Target version changed from 1.1.0 to 1.1.1
Actions #4

Updated by Shivani Bhardwaj about 5 years ago

  • Status changed from Assigned to Feedback
Actions #5

Updated by Jason Ish almost 5 years ago

  • Target version changed from 1.1.1 to 1.2.0
Actions #6

Updated by Shivani Bhardwaj almost 5 years ago

  • Status changed from Feedback to Closed
Actions #7

Updated by Jason Ish about 4 years ago

  • Target version changed from 1.2.0 to 1.2.0rc2
Actions

Also available in: Atom PDF