What if /usr is (mostly) read-only

[jlecour]

Hi,

I'm used to have the /usr partition as "read-only". It's a security policy.

I'm using Debian and with apt there is an easy way to remount the partition as "read-write" before installing a package and then back to read-only after. In the Debian ecosystem it's quite an usual habit and it's more and more taken into account at the distribution level.

With this Ansible role, I can't install the SystemD unit.

I think we can deal with this with a couple of action that would detect if /usr is a separate partition and if it's read-only. Then it would do the remount dance around installing the SystemD unit.

What do you think about this?

[jordansissel]

What if the systemd unit was installed to /etc instead? Or is that also
read only? As an alternative, for your own environment, you could set read
write at the start of your ansible run and then read only after? Or add an
selinux policy to allow the changes only through ansible but otherwise deny
changes to files?

(Just brainstorming)

On Friday, September 9, 2016, Jérémy Lecour notifications@github.com
wrote:

Hi,

I'm used to have the /usr partition as "read-only". It's a security
policy.

I'm using Debian and with apt there is an easy way to remount the
partition as "read-write" before installing a package and then back to
read-only after. In the Debian ecosystem it's quite an usual habit and it's
more and more taken into account at the distribution level.

With this Ansible role, I can't install the SystemD unit.

I think we can deal with this with a couple of action that would detect if
/usr is a separate partition and if it's read-only. Then it would do the
remount dance around installing the SystemD unit.

What do you think about this?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#150, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIC6oR7GHdSQAjCe8grLXb_vAVhEub3ks5qoQgigaJpZM4J4xFk
.

[jlecour]

For the moment, I do the remount as "read-write" before executing the tasks, so it works,but it would be great to have it done in an automatic way "in the role".

Writing the unit in /etc is a good idea too (can it be done with the service module ?).
It's mounted as "noexec" (no reason to exec anything in /etc) but being able to write to /etc too frequent to be limited.

Thanks for your advice.

[jakommo]

For the moment, I do the remount as "read-write" before executing the tasks, so it works,but it would be great to have it done in an automatic way "in the role".

IMHO this should be handle in a role/task dedicated to your env. It's kind of a special case related to your env and not directly related to ES.
I'm open for discussion, but I think handling special cases like this will just make the role bigger. Also it's harder to test, as we would need a special Image/Container just for this.

thoughts @gingerwizard @jpcarey ?

[jlecour]

I see your point, but it's more and more a common case to have /usr mounted as read-only.
Also, dealing with this in my part of the playbook is not that easy. Here is why

When you have /usr mounted as read-only, you typically configure apt to auto-remount it as read-write before installing packages and re-remount it back to read-only afterwards.
Since the package is installed by the "elasticsearch" role, if I want to use it without modifying it, whatever I do before executing the role, the partition will be remounted as read-only before installing the service file.

Maybe putting the service file in /etc/ is the (kind of) best option. Don't you think ?

[jlecour]

I'd add this, from the Filesystem Hierarchy Standard :

/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.

It seems quite clear that the SystemD service file shouldn't be written to /usr :)

[jordansissel]

FHS is a very poorly detailed document. Let's leave that out.

It is not common to have a read-only mount for /usr. Debian and red hat
distros both default in most cases I remember to having a larger /
partition that includes /usr and is mounted RW.

On systemd systems, unit files can go in /etc or the systemd directory
(/lib/systemd or /usr/lib/systemd, depending on the distro)

On Tuesday, September 13, 2016, Jérémy Lecour notifications@github.com
wrote:

I'd add this, from the Filesystem Hierarchy Standard
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY :

/usr is the second major section of the filesystem. /usr is shareable,
read-only data. That means that /usr should be shareable between various
FHS-compliant hosts and must not be written to. Any information that is
host-specific or varies with time is stored elsewhere.

It seems quite clear that the SystemD service file shouldn't be written to
/usr :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#150 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIC6hINnB5BMapeuM9IcSsa0k-Gsit3ks5qpq7tgaJpZM4J4xFk
.

[jakommo]

It seems quite clear that the SystemD service file shouldn't be written to /usr

Well it wasn't us who decided to install the systemd files in that location by default, that probably something the distros decided. (Esp on RHEL/Fedora)

I'm also against moving it to /etc/ as this will cause confusion. E.g. users expect it being in /usr as it's the default with the deb/rpm.

Can't you just remount rw when the playbook start and remount ro at the end?

We discussed this internally and decided not to include such a mechanism in this role. Sorry.
Closing.

[jlecour]

I disagree but understand that you don't want to take that use case into account.

In fact I can't mount the partition as "read-write" before the role is executed because Apt has a hook around a package install and will remount as "read-only" right away. Since there is no hook in the role, I'm screwed.

I guess I'll have to fork the role and maintain my own version.

Thanks anyway for the discussion about this.

[sourcejedi]

I don't understand, /etc is the expected location for administrator-configured files. /usr is reserved for files installed by the OS, which should not be edited. You can see this in the behaviour of systemctl edit --full.

[jlecour]

Exactly ! That's what I was trying to explain, but I guess I wasn't very convincing.

[jakommo]

Guys, we are just following the convention of the Elasticsearch RPM/DEB package here.
Feel free to report this upstream. I just don't want to place the file in a different dir as the RPM/DEB would, as this might cause confusion. (The different name already does #205)

[sourcejedi]

Sorry, I shouldn't have commented on the decision. This discussion came up when I searched for general information.

RPM/DEB packages using /usr is expected. Now I see the installed service has a different name, I understand you want to put the files side-by-side. I don't think that's a common convention but of course it's your decision.