You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Well... I was just trying to check out this software and I tried to do it right and package it for my operating system.
I've changed the prefix to /usr as usual (and also patched piranha to use more standard paths like /var/lib/piranha, /usr/share/man, /var/log, etc., and respect DESTDIR in the makefile to support installing into a temporary install directory for packaging, but that isn't relevant in this case) and merged the package into my system. Piranha failed to start with some error message (something with socket, I don't have the respective terminal open anymore, but it isn't relevant to this case either).
The command to start piranha was sudo /usr/bin/piranhactl start (as I said, I installed to standard system paths).
After that I had to notice that sudo didn't work anymore and I had to manually fix it by running:
This causes piranha to chown() the whole /usr directory as during configuration --prefix=/usr was set, causing -DPATH=/usr to be set as compiler parameter and thus causing this line to chown /usr.
This is very dangerous.
--prefix is a standard configure option which is used for build systems to differentiate between a local installation (where not package manager is used) to /usr/local and a package manager installation to /usr. To abuse this option in a different way is not only confusing (at least my system broke because of that), but dangerous. You chowned the whole /usr tree to nobody. I was lucky to have a root password and that /bin/su wasn't affected by this. Otherwise my system would have been become more or less unusable without breaking into it using a live ISO.
--prefix is meant to point to an installation prefix for files which do not change and the only software that applies any changes in the prefix directory should be the package manager, not a service executable. You should use a different location inside /var (like /var/lib/piranha – the home directory of the system user piranha) for variable files.
If you don't intend to make piranha installable system-wide, please deprecate and remove the --prefix option so other people don't get confused again.
My personal suggestion is retrieving the various paths via command line parameters ant configure time with sensible defaults, like /usr/local als prefix, /var/lib/piranha as variable files directory, /var/log/ as logging directory, etc. and moving any necessary chown calls from runtime to the install phase where in most packaging systems all calls happen in a sandboxed or otherwise secured environment without causing harm to the system. That way, package managers can also detect collisions with the installed directories' owner/group/umask settings and report a possible misconfiguration.
Please forgive me that I could write only bad things in this issue, but this is a very dangerous matter and because of this I am currently not very motivated to do any further testing of your software as I don't want to risk further problems with my system. The current state of this software makes it too dangerous for me to use it.
The text was updated successfully, but these errors were encountered:
Well... I was just trying to check out this software and I tried to do it right and package it for my operating system.
I've changed the prefix to
/usr
as usual (and also patched piranha to use more standard paths like/var/lib/piranha
,/usr/share/man
,/var/log
, etc., and respectDESTDIR
in the makefile to support installing into a temporary install directory for packaging, but that isn't relevant in this case) and merged the package into my system. Piranha failed to start with some error message (something withsocket
, I don't have the respective terminal open anymore, but it isn't relevant to this case either).The command to start piranha was
sudo /usr/bin/piranhactl start
(as I said, I installed to standard system paths).After that I had to notice that
sudo
didn't work anymore and I had to manually fix it by running:Then I had a look at the source code and noticed something very dangerous:
piranha/src/p_piranha.c
Line 86 in 7bedeee
This causes piranha to
chown()
the whole/usr
directory as during configuration--prefix=/usr
was set, causing-DPATH=/usr
to be set as compiler parameter and thus causing this line to chown/usr
.This is very dangerous.
--prefix
is a standard configure option which is used for build systems to differentiate between a local installation (where not package manager is used) to/usr/local
and a package manager installation to/usr
. To abuse this option in a different way is not only confusing (at least my system broke because of that), but dangerous. Youchown
ed the whole/usr
tree tonobody
. I was lucky to have a root password and that/bin/su
wasn't affected by this. Otherwise my system would have been become more or less unusable without breaking into it using a live ISO.--prefix
is meant to point to an installation prefix for files which do not change and the only software that applies any changes in the prefix directory should be the package manager, not a service executable. You should use a different location inside/var
(like/var/lib/piranha
– the home directory of the system userpiranha
) for variable files.If you don't intend to make piranha installable system-wide, please deprecate and remove the
--prefix
option so other people don't get confused again.My personal suggestion is retrieving the various paths via command line parameters ant configure time with sensible defaults, like
/usr/local
als prefix,/var/lib/piranha
as variable files directory,/var/log/
as logging directory, etc. and moving any necessarychown
calls from runtime to the install phase where in most packaging systems all calls happen in a sandboxed or otherwise secured environment without causing harm to the system. That way, package managers can also detect collisions with the installed directories' owner/group/umask settings and report a possible misconfiguration.Please forgive me that I could write only bad things in this issue, but this is a very dangerous matter and because of this I am currently not very motivated to do any further testing of your software as I don't want to risk further problems with my system. The current state of this software makes it too dangerous for me to use it.
The text was updated successfully, but these errors were encountered: