guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Dinse <>
Subject Re: guacd not starting on boot
Date Mon, 11 Mar 2019 11:37:41 GMT

      /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/

  Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
    Knowledgeable human assistance, not telephone trees or script readers.
  See our web site: (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 <>
> Reply-To:
> To:
> Subject: Re: guacd not starting on boot
> On Sun, Mar 10, 2019 at 11:04 PM Robert Dinse <> 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/" 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:
>>     to:
>> 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
> 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

View raw message