ufw user.rules should be stored in /etc

Thank you for using ufw and reporting a bug. I understand where you are coming from with regard to backups and the desire to have the files in /etc. The user*.rules files are not intended to be modified by a person, but instead by the ufw CLI command. /lib is not the perfect place, but it is the best place considering practicality and the FHS shortcomings. See http://www.pathname.com/fhs/pub/fhs-2.3.html.

Specifically, the user*.rules files are considered 'state' files and not 'configuration' files and according to the FHS, the proper place is actually in /var ("State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package's operation"). Indeed, this is where ufw originally stored the user*.rules, but alas this can't be done due to bug #400208. ufw starts extremely early in the boot process, way before /var is mounted. /etc could make sense, and I thought about putting it there, but this would likely lead to misconfiguration and these files much more fit the definition of state files anyway. Which leaves the imperfect '/lib'. The title of section in the FHS is 'Essential shared libraries and kernel modules'. That certainly doesn't sound right, but reading the description of 'The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin'. That sounds more like what we need. udev was looked at as a precedent, though admittedly it uses static text files as opposed to the more volatile ufw user*.rules files.

In short, the rationale is:
a) the user*.rules are state files, not configuration files
b) user*.rules should be in /var, but cannot due to when ufw is started during system boot
c) user*.rules shouldn't be in /etc because they are state files, and if they were there people could easily break ufw when modifying them by hand
d) user*.rules are put in /lib because this addresses a-c and because the files are needed to bring up the system

I don't particularly like the files in /lib with the current specification, but the FHS doesn't currently address situations where you need state files in the early boot process.

+1 for moving to /etc so they can be revision controlled with etckeeper. Also, the system's firewall rules should be backed up when backing up the system config and while /etc generally is, /lib may not be.

I know this bug is closed for two years now, but i think it should be re-opened for reconsideration.

Storing system-specific state data in /lib violates the Principle of least astonishment!

This issue does not only affect users of "etckeeper". When backing up, monitoring, tracking a file system, or migrating a system to a new server, one usually looks for server specific content here:
 * /etc /var /home
 * Maybe /opt, /usr/local, or /root depending on your habits

If there is any other place that contains data, then only because of some software that i installed and configured, so i should know about it.

OS-level software that stores state data anywhere else is a very unpleasant surprise. /lib/ is the last place i would expect system data in that i might want to migrate to a new server.

I understand that ufw cannot have it's state data in /var because of the mount issue.

But /etc is a perfect place for it. Nowadays /etc is *full* of machine-generated state files that should not be manually edited. E.g. on my system (ubuntu 13.04) i find this in my /etc/resolv.conf:

  "# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN"

I suggest to move the ufw state files into /etc/ and prefix them with a "AUTO GENERATED, DO NOT EDIT" disclaimer.

Comparing the two options, i clearly prefer /etc:
 * State files in /lib: People might lose their rulesets because they aren't aware they are stored in /lib
 * State files in /etc: Stupid people might conciously ignore a bit fat warning and manually edit the ufw state files just because they are in /etc

I second Nils' request of course ;-)

The data "what commands have been given to ufw" is not just ufw state precisely because ufw stores them and will restore system to that state on boot. It is configuration about what ufw should do when it is started. Just like e.g. /etc/network/interfaces is not networking state data, but configuration about what networking services should do on start.

A good comparision might be NetworkManager it stores its configuration underneath /etc/. The config files that are intended for admin editing (/etc/NetworkManager/NetworkManager.conf) as well as ones that are intended to be managed by NetworkManager GUIs/TUIs (/etc/NetworkManager/system-connections/).

Same OpenVPN (/etc/openvpn/*.conf vs. /etc/openvpn/ipp.txt)

UFW is the only piece of software i know about that separates permanent-configs-that-are-usually-machine-generated away from not only the its regular config dir, but even out of {/etc,/var} altoether.

Again, I see good reasons to store the ufw in /etc.

* It would improve usability, and help backup / tracking (etckeeper). Also it follows usual expectation that configuration should be in /etc. Note that there are other packages that would originally store there configuration files in /var, but distributions like Debian (and Ubuntu) fix this by moving these to /etc and add symlinks (e.g. qmail).

* This will store configuration files at the correct place, which tmo is more important that storing some "state" files at the correct place. The former brings a usability problem, where the latter only possibly breaks general conventions.

* There is no risk of breaking the system more than already is. There are many sensitive files in /etc that a user could edit and break the system (but you need to be root). I don't think this is a valid point.

So to sum up, this is convention vs usability issue. In this case we can't satisfy conventions correctly anyway, so I think it's best to favor usability.

Tiger UNIX security checker doesn't like this either.

"""
--WARN-- [lin001w] File `/lib/ufw/user6.rules' does not belong to any package.
--WARN-- [lin001w] File `/lib/ufw/user.rules' does not belong to any package.
"""

This brought me here.

I ran into this when trying to put my /etc under version control. My hack workaround (which seems to be working) is to hard link the files into /etc/ufw.

I would like to see the configuration files moved to /etc, possibly with a large comment at the top stating that they should not be edited, and warning that doing so WILL cause undefined behavior.

Sorry for the bug mail spam, but I've been poking at the ufw source and thinking about it some more, and I just can't let this go. =)

Perhaps the *real* bug is that there is not a clean separation between configuration and state date. Ideally, a .conf file in /etc would look somewhat (exactly?) like what you would type on the command line to generate the firewall rules. (I won't name names, but I've seen many commercial firewalls that do it this way.)

The "state", then, could be regenerated from the configuration, and would correspond to what ufw expects to be installed in iptables, or what it *would* expect to be installed if it were active. Sure, you can install it in early boot, if required (for example, if you don't yet have python available), but it should be regenerated later in the boot process, and the state should be updated if it's out of sync with the configuration.

Since ufw doesn't have an intermediate configuration layer right now, its state is also its de facto configuration. This thread is full of examples of machine-generated "DO NOT EDIT" files in /etc, but I'd add the argument that de facto configuration files are still configuration files, even if they're [nearly] impossible to hand edit. (see sendmail.cf, for example - the supported way to edit it is to use m4!) Ideally ufw should move from de facto configuration to explicit configuration.

Here's another example use case: it should be easy to take a set of firewall rules, clearly spelled out in a configuration file, and copy/paste those rules - possibly with minor edits - to another system. Unless I'm mistaken, right now the only way to do that with 'ufw' is to manually interpret the output of the 'ufw status'.

Also note that storing config or state data in /lib is a violation of the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/pub/fhs-2.3.html) and hence of LSB. According to those standards, such data should go to /etc, /var or /srv. If /var is ruled out because of late mounts, then /srv probably too, so /etc is the only remaining standard-compliant option.

I call this a bug in the file layout, not just a wish.

But i have a feeling that once a ticket has been set to "won't fix", no one with the power to re-open it bothers to read the thread and reconsider. What would we have to do to gain attention?

The FHS concerns are discussed in comment #1.

Some commentors here argue that for various reasons /etc is a much better choice for early-boot state files than /lib. Could you address those arguments?

I throw in another one: in some environments (e.g. shared NFS rootfs; or embedded devices with union-mount /etc), /lib is read-only, along with /bin, /sbin and /usr. This is explicitly allowed by FHS, while FHS expects /etc to be read-write.

Hi Jamie,

Thanks for feedback. Sorry for the PM earlier on, I did not see your reaction above.

In general, there is no perfect decision in this case. However, from various posts above, it seems that storing the config files in /etc would provide better usability in many scenarios.

I don't agree with your comment #1. Your main objections (a) and (c) are only prospective considerations that are careful and wise, but in this case, they only try to avoid a possible problem with unspecified likelihood, whereas storing these files in /etc would provide a clear and immediate usability benefit.

Note, my response in #12 was not dismissive of the feedback-- it was merely restating that FHS was considered and /etc is non-compliant as well. I've marked the bug as Confirmed. I want to think about this more.

For what it's worth, in Gentoo ufw is patched to use /etc.
It makes it easier for the package managers to handle the files (there is another way, but this one looks cleaner).

I vote for #3

Sorry, I'm another vote for the config info moving to /etc. Putting it in /lib makes my life more difficult in tracking config changes.

The argument that it is state information really does not hold water for the following two reasons. First, state info belongs in /var, not /lib. So if you're not going to put it in /var, put it in /etc. Second, it's not state info. It's configuration. If I enable ufw and then run a new ufw allow/deny command the rules files will be updates but the running state will not be changed (and worse still, ufw status won't show that but that's a different bug). The rules files capture the configuration ufw will use the next time it is enabled or reloaded - they do not capture state.

It might be nice if ufw did capture state - it might then be able to provide diffs between its on-disk configuration (in /etc) and its current running state (in /var or in /run). But the files in /lib are not capturing state.

This bug should be reopened and this bug should be fixed.

This is insane.

I just had to scratch ufw rules for a VPN server that we redeployed from some system image snapshot because of course no one thinks of adding anything in /lib/ to backup, leave alone the tarball with the migration-config+data

Everywhere else, you are on the safe side if you backup /etc, /var, /home and (depending on your habits) maybe /opt and /usr/local. But not with ufw!!

Please fix this. ufw is currently an outlyer that breaks standard DevOps assumptions everyone works with. Very annoying.

Also i am not sure ' Wishlist ' is the appropriate importance. There is a very real risk that ufw rules do not get included into backup, or that typical company policies like mandatory config control (tracking/monitoring/versioning) miss it.

This will be fixed in 0.35.