/var/run is a tempfs file system and recreated at each boot so changing
the perms on it are gone on the next boot. As for the encryption key, lots
of things run as daemon, I don't want them all having access to the key.
At any rate, that's my suggestion for functionality.
I still have some other issues to work out but they're with my hosts
not with guacamole. I have sound working on debian and mint. Have not been
able to get it to work on ubuntu yet nor on any redhat derived system, I get
connection refused from the pulseaudio port on those machines even after adding
the suggested configuration change to /etc/pulse/default.pa.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
Knowledgeable human assistance, not telephone trees or script readers.
See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Mon, 11 Mar 2019, Nick Couchman wrote:
Date: Mon, 11 Mar 2019 07:06:40 -0400
From: Nick Couchman <vn...@apache.org>
Reply-To: user@guacamole.apache.org
To: user@guacamole.apache.org
Subject: Re: guacd not starting on boot
On Sun, Mar 10, 2019 at 11:04 PM Robert Dinse <nan...@eskimo.com> wrote:
Ok, rebuilt with the correct --with-systemd-dir=/lib/systemd/system
and
now I had more problems. Launched out of init.d it ran as root, launced
out
of systemd, the unit file it created has User=daemon so it runs as daemon.
Problem with that is only root has access to /var/run and to the
encryption key
file so I changed it back to root despite that being less secure.
Or you could change permissions on the files so that the daemon user has
access to them. For the encryption key, this should be pretty
straight-forward:
chown daemon /path/to/encryption/key
For /var/run, I'm not sure why the daemon user would need access to that
directory? I suppose it could if you're adding "-p /var/run/guacd.pid" to
the command line or specifying a PID file in the guacd configuration, but
by default there are no requirements for this. Furthermore, with systemd
in particular, I'm not sure that's there much value to having it generate a
PID - system runs things in the foreground by default and manages tracking
the PID of the daemon, so there's really not much you'd need the PID file
for.
If you do want that PID file in /var/run, for whatever reason, in most
distributions that run systemd /var/run is managed by tmpfilesd, and can be
configured by adding the appropriate file to /etc/tmpfiles.d with the files
and/or directories and the required ownership and permissions.
Lastly it still failed because it tried to start before /misc was
mounted
which is where the key file was so I modified the unit file line:
After=network.target
to:
After=network.target misc.mount
/misc is the file system where I have the encryption certs and keys.
Now it starts properly after a reboot. Downside, as with when it ran
out of /etc/init.d, it is running as root which from a security perspective
is undesirable.
But, this is your choice, not a requirement - you've changed it from daemon
to root to resolve other issues that should be resolved with either a chown
(or ACLs) and proper configuration.
What guacd should have is an item that goes into guacd.conf for user
and
group so it can start as root, write the pid file and read the necessary
cert and key files, and then switch to said user and group just like Apache
httpd and tomcat do.
httpd does this, Tomcat does not. Tomcat is started by the startup.sh
script, and that script must be run under the account that you want running
Tomcat. Tomcat does not implement user context switching at startup, and
should (IMHO) *never* be started as root.
Then it could be both secure and functional.
There may be some value to looking into doing this - having the initial
user be root and then switch to another user - but please understand that
it is not required to make guacd both "secure and functional" as it is
implemented today. There is no reason at all that you cannot set
permissions on all of the required items - GUACAMOLE_HOME (/etc/guacamole),
encryption keys and certificates, and the necessary /var/run entries - to
the user specified in either the init script or the systemd file (+
tmpfiles.d) so that guacd runs under a non-root account. You don't have to
use the daemon user if you don't want to - this was a convenient default
for the systemd unit file when we added it - you can create a separate user
for guacamole (I often use "guac") and change permissions to that user
along with the systemd script, and you will be able to operate in both a
"secure and functional" fashion.
Furthermore, there are other methods you could use to protect guacd and the
required files, like chroot jails or Docker containers. Docker is already
available, and, while chroot jails are not implemented by default, the
requirements for guacd are reasonably simple enough that it should be
doable with minimal effort.
The point here is that, while there may be some value to having guacd start
under root and switch internally, there's no reason you have to do this in
order to make guacd function and function securely.
-Nick
