<html><head></head>
<body><div>Hi John,</div><div><br></div><div>So I think there is a happy medium but my experience is that people do not like spending forever battling SELinux, so someone has not come up with a comprehensive list. &nbsp;I can add in a few more options to allow read/write for Bazaar plugin installation. &nbsp;I would suggest:</div><div><br></div><div>chcon -R -h -t httpd_sys_script_rw_t [eprintspath]/lib/</div><div>chcon -R -h -t httpd_sys_script_rw_t [eprintspath/archives/[archivename]/bin/</div><div>chcon -R -h -t httpd_sys_script_rw_t [eprintspath]/archives/[archivename]/cgi/</div><div>chcon -R -h -t httpd_sys_script_rw_t [eprintspath/archives/[archivename]/cfg/</div><div>chcon -R -h -t httpd_sys_script_rw_t [eprintspath/archives/[archivename]/html/</div><div>chcon -R -h -t httpd_sys_script_rw_t [eprintspath/archives/[archivename]/var/</div><div><br></div><div>I am surprised archive level var and html are not already there, as I have to reckon that Apache would certainly create a lot of files in the latter and there are admin options that need to be able to update timestamp files in the archive's var directory.</div><div><br></div><div>If you have meprints you would also need:</div><div><br></div><div>chcon -R -h -t httpd_sys_script_rw_t [eprintspath/archives/[archivename]/meprints/</div><div><br></div><div>It may be easier to allow the whole archive directory but if you have an ssl directory with a key in it, you certainly would not want to leave open any way for Apache to be able to overwrite this. &nbsp;As the Bazaar can install new bin and cgi script unfortunately you cannot lock down these directories at an archive level. &nbsp;The cgi directory would be slightly easier to exploit, as the bin directory would reply on a cron job existing that runs the script or a command line user running it by hand.</div><div><br></div><div>That all said, it is probably sensible to use semanage rather than chcon, so that the rules persist, otherwise if restorecon is run all these rules would be lost.</div><div><br></div><div>Regards</div><div><br></div><div>David Newman</div><div><br></div><div><br></div><div>On Thu, 2018-06-28 at 09:34 +0000, John Salter wrote:</div><blockquote type="cite"><div>Hi All,</div><div>There's just been an exchange on the eprints-uk-user-group mailing list, where someone was having issues getting EPrints up and running. The root cause was SELinux.</div><div>&nbsp;</div><div>On this page:</div><div>http://wiki.eprints.org/w/Installing_EPrints_on_RHEL/Fedora/CentOS#Using_SELinux</div><div>there is some advice - but it doesn't seem to cover any of the directories that things like the Bazaar would need access to (e.g. ~/lib/plugins/).</div><div>It also doesn't include [eprintspath]/archives/[repoid]/html/ - which means summary-pages fail to be written when an http request causes them to be regenerated.</div><div>&nbsp;</div><div>This message (from 2015) http://threader.ecs.soton.ac.uk/lists/eprints_tech/21145.html suggests granting r/w permission for the whole eprints install directory (/usr/share/eprints/).</div><div>&nbsp;</div><div>Is this the most sensible option?</div><div>Should e.g. ~/perl_lib, ~/bin, ~/cgi &nbsp;be more locked down?</div><div>&nbsp;</div><div>Cheers,</div><div>John</div><div>&nbsp;</div><div>PS There is also this note: http://wiki.eprints.org/w/Troubleshooting#A_Note_on_SELinux - but that references EPrints2 - so probably a little outdated.</div><div>*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech</div><div>*** Archive: <a href="http://www.eprints.org/tech.php/">http://www.eprints.org/tech.php/</a></div><div>*** EPrints community wiki: <a href="http://wiki.eprints.org/">http://wiki.eprints.org/</a></div><div>*** EPrints developers Forum: <a href="http://forum.eprints.org/">http://forum.eprints.org/</a></div></blockquote></body></html>