That hosts file is depressing. Blocking trackers by a1.tracker.name, a2.tracker. name etc. Today it seems easier to have a whitelist rather than blacklist...

I also don't understand systemd integration in the todo.

The goal here is to make it automatically update the hosts file once in a while

Doesn’t automation of editing your hosts file potentially open people up to fairly insidious man in the middle attacks?

Isn’t that what cron is for?

Systemd has a cron system too.

I’m just guessing, but it might be easier to programmatically install a systemd cron job (and making sure it runs) than doing so for the old/conventional crond?

Just using cron is back compatible

Things you get with systemd that you don't get with cron unless you implement them in the script.

* Not running if the network is down.

* Not running if the download path isn't available.

* Running if the machine was off during the scheduled time.

* Monitoring and retry logic.

* Logging to syslog.

* Resource constraints.

* Random wait.

It ends up being a lot of code factored out of the actual application.

so instead of code in one place you have it in 2?

I don’t understand this logic. Can you explain why having code in more than one place is a bad thing?

For a simple script that does one thing, it's overkill.

Yes. So you keep that simple script simple, and you let systemd do the heavy lifting.

But systemd doesn't do any of the above listed things automatically... You'd need to write an entire script for sytstemd to take advantage of it. An entire script you could just have run with cron on boot.

He probably wants to learn more about systemd and needs/wants a project to do it.

Yes, obviously cron would work. If systemd can do what this dev needs, what's the harm?

You're right, but I like the extensibilty of Systemd. Things like running every week or whenever the next start is. Or only if the network is online.

If I considered constructing a botnet of Linux workstations, your software would be an excellent candidate.

You could say the same thing about Ansible, or Chef or Puppet or any of the other millions of systems automation tools available. There are lots of ways to misuse software, I don't think that that should preclude people from writing it.

I'm quite precise about about what these tools can and cannot do on my systems. Downloading random files form the Internet isn't on the list. When you hand over the control of the hosts file to someone else, you're basically transfer control of your DNS queries.

At least for HTTP, you're hopefully using TLS for anything important and failing if the certificate isn't valid. That certainly won't remove all the risks of losing control of your DNS, but it's one good safeguard.

Some of my favorite hacks in the last year have been about using valid certs for bad actions. When you can have a cert from Microsoft (Azure), there’s a lot of things people will trust.

Along similar lines, I think I heard that 30% of detected malware was signed with a “trusted” authority last year.

Why?

I don't understand the downvote.

1. What is so bad about python in specific?

2. If you worry about root privileges, required for modifying the host file, you can use app armor to put the thing on a leash

Why not?

Modifying system hosts configuration requires privileged file system access.

The mindset here should be default deny.

Yep, finding and modifying a script that runs with root privileges, but is writable by non-root users is the oldest privesc trick in the book.

With the proper permissions something like this should be ok, but I'd tread lightly. Especially with something that dynamically updates your hosts file.

It won't be able to run if the user that is running it doesn't have the proper privileges. You could even protect the files by giving them other permissions so only the root user can use them.

Above you mentioned setting this up as a scheduled job. In this case the job would need to run as root (or you'd need to assign the appropriate permissions in the sudoers file, but people are lazy). If a non-root user had write privileges to the file, they could modify the script and thereby gain root code execution.

Naturally it's on the user to properly configure the permissions.

I'm not saying this isn't a worthy project, I'm just adding to the discussion on why people should be cautious when running scripts with root permissions.