Glassfish is installed and run as root

[bencomp]

The installer script (#1119) requires that it be run as root. Glassfish is installed by this script, possibly making root the owner of the Glassfish server.

In our test environment, Glassfish now runs as the root user.

I am told running Glassfish as root is very bad practice and unnecessary. As we followed install instructions closely, I suspect the script is in some way responsible and would like to have this reviewed.

Does Glassfish on IQSS's servers also run as root?

[pdurbin]

In Vagrant at https://github.com/IQSS/dataverse/blob/master/scripts/vagrant/setup.sh I unzip the Glassfish zip file as non-root, at least. But I believe @bencomp is right that the installer (called by the Vagrant scripts) later starts Glassfish as root: https://github.com/IQSS/dataverse/blob/master/scripts/installer/install

@bencomp if you want to mess around with the installer to have it do more stuff as $GLASSFISH_USER I'd be happy to review a pull request!

[pdurbin]

Yesterday in #glassfish on freenode @phillipross was making the point that iptables can be used for port forwarding. This is something I could play around with in Vagrant some day, perhaps, but as of this writing we're hoping to reintroduce Apache in #2180 in order to restore Shibboleth support for #2117. That is to say, I probably wouldn't bother with the iptables port forwarding unless we choose a non-Apache direction for Shibboleth support (such as using a Java library like OpenSAML right in the app itself).

Anyway, I share the sentiment that we should avoid running Glassfish as root if we don't have to.

[bencomp]

I was told that Apache very briefly gets root access to 'claim' ports under 1000 (80 and 443) and then goes into a non-root mode for normal operation.

[pdurbin]

Right, "In typical operation, Apache is started by the root user, and it switches to the user defined by the User directive to serve hits." http://httpd.apache.org/docs/2.4/misc/security_tips.html

For CentOS, see http://serverfault.com/questions/355223/centos-httpd-running-as-both-root-and-apache-user/355230#355230

See also discussion at http://irclog.perlgeek.de/crimsonfu/2015-07-09

[pdurbin]

In #2443 @michbarsinai and I have discussed the need for a "developer-machine friendly setup script" that does not require root.

Also, these days we're back to running Glassfish behind Apache on https://dataverse.harvard.edu per #2180 so there's no need to run Glassfish on a low port. Glassfish runs on its normal high ports (8080 and 8181) and doesn't need to be started as root.

[pdurbin]

In pull request #3017 it says the installer no longer has to be run as root.

[pdurbin]

@donsizemore must be taking advantage of the "NEW in Dataverse 4.3: It is no longer necessary to run the installer as root!" feature added in pull request #3017 because he mentioned the other day that Odum/UNC doesn't run Glassfish as root: https://groups.google.com/d/msg/dataverse-community/U04sLtEkJ7Q/TB-xvjXHBQAJ

He wrote, "Dataverse.unc.edu is running RHEL7 with Shibboleth 2.6, with each service (glassfish, httpd, rserve, shibd) running as separate, non-privileged users."

[pdurbin]

@donsizemore and I talked about this at http://irclog.iq.harvard.edu/dataverse/2017-02-02#i_48097

My main take away is that by default, Don's Ansible code at https://github.com/IQSS/dataverse-ansible runs Glassfish with a dedicated non-root user called "glassfish". This is a great default to have.

[donsizemore]

I install glassfish as root but give the glassfish user ownership of /usr/local/glassfish4/glassfish/domains/domain1 and the JVM-specified filesdir. Protects Glassfish from itself, and so far, so good.

[pdurbin]

We should document in the Installation Guide how to run Glassfish as a user under than root. I wonder if the currently suggested init script will need to change: http://guides.dataverse.org/en/4.6/installation/prerequisites.html#glassfish-init-script

In addition, I assume the installer will need to be updated as well, from a quick peek at https://github.com/IQSS/dataverse/blob/v4.6/scripts/installer/install I don't a variable for $GLASSFISH_USER, for example.

Hmm, I'm reading "NEW in Dataverse 4.3: It is no longer necessary to run the installer as root! Just make sure the user that runs the installer has the write permission in the Glassfish directory." at http://guides.dataverse.org/en/4.6/installation/installation-main.html#running-the-dataverse-installer . Perhaps that means that one should create a user called glassfish or whatever and then run the installer as that user? More investigation is needed. I always just run the installer as root, both manually and in Vagrant. Vagrant would be an excellent place to place to test out any changes to the installer.

[donsizemore]

@pdurbin if you assume that new installations will move to RedHat/CentOS 7 you could include a sample glassfish.service file for systemd. c.f. https://github.com/IQSS/dataverse-ansible/blob/master/roles/dataverse/templates/glassfish.service.j2 and https://github.com/tdilauro/dataverse-ansible-role/blob/master/roles/dataverse/templates/glassfish.service.j2

in my experience at Odum Glassfish just needed to own the domain1/ hierarchy and files.dir/

dataverse-ansible does this by default; you could just make vagrant create a glassfish and you should be good.

[pdurbin]

In recent memory we estimated this issue as a "5" which you can see at https://waffle.io/IQSS/dataverse?search=1934

I just closed #3607 but we could re-confirm if it's possible to deploy via POST when we start work on this issue.

[pdurbin]

@donsizemore made pull request #3991 (thanks!) and I just advanced it to Code Review per http://guides.dataverse.org/en/4.7/developers/version-control.html#make-sure-your-pull-request-has-been-advanced-to-code-review

[pameyer]

Looks good to me: CentOS 6 init script for glassfish; running installer as glassfish user (non-interactively); after installer glassfish isn't running as root. No problems w\ emails, no problems creating users/dataverses/datasets (didn't check publishing due 3957 / current provisioning setup; but don't see any reason it would have problems).

[pdurbin]

The thing that really gave me confidence yesterday at standup was hearing that @pameyer is using these new init scripts. Awesome.

[donsizemore]

@pdurbin I tested the CentOS6 example before including it, and Odum has been using the Systemd example in production for nearly a year.

[landreev]

Kevin just tried to run the installer as root (something a user still should be able to do, if, against our recommendations, they still have some reason to run glassfish as root...); and it failed with 'no such user "glassfish"'.
So it looks like the username is hard-coded in the installer:

my %CONFIG_DEFAULTS = (
...
    'GLASSFISH_USER',	   'glassfish',

We really want it to be configurable; i.e., it needs to be added to "@CONFIG_VARIABLES", with an extra entry in "%CONFIG_PROMPTS".

The message early on says "Consider creating a glassfish service account..." - not "you must create a non-root account, and the name must be 'glassfish'". I think this is the correct approach; but then the installer script should behave accordingly.

[landreev]

Oh, another thing is, this script is not just for admins setting up dataverse servers - all the developers who want to contribute to the project have to run it too. And for a developer the recommended setup is to just run Glassfish as themselves; i.e. their normal unprivileged user id.

So the ideal behavior would be for GLASSFISH_USER to default to the current user, unless it is root - in which case to "glassfish". But, if it's too much hassle, defaulting to "glassfish" is ok, as long as it's configurable.

[donsizemore]

whoops! will fix. thank you for the feedback.

[donsizemore]

Okay, I think I have this right. The updated script:

• warns if run as root but carries on
• checks default.config for GLASSFISH_USER
• checks CLI arg for gfuser, which trumps default.config
• falls back to current user per ENV or getpwuid

I tried a number of combinations to test precedence, but was interrupted and... I think I have it right. Additions or corrections are welcome and requested.

[landreev]

Thanks @donsizemore! - looking great.
@kcondon is back tomorrow, he should be able to do his final QA check and merge your branch quickly.