CCI-MOC
Permissions Issue
BMI currently reads or writes or both to these folders /etc/bmi/bmiconfig.cfg /etc/tgt/conf.d/ /var/lib/tftpboot/ /var/lib/tftpboot/pxelinux.cfg/ /var/log/bmi/
We were having some crashes due to permission issues. Unfortunately it is a bad idea to run bmi as root due to basic security concerns. The right way to run bmi as a user with password less sudo access and with default permissions, but different ownerships.
/etc/bmi/ owned by root:root /etc/tgt/conf.d/ should not be used as /etc/* typically consists of conf files which are typically modified by humans not programs. The right way to do it is to use a special program that modifies the conf files (which doesn't exist) or use the tgtadm commands (after doing research the tgt-admin --execute converts the conf file into tgtadm commands) or generate the conf file in /tmp and use tgt-admin --conf option. /var/lib/tftpboot/ bmi:bmi /var/lib/tftpboot/pxelinux.cfg/ bmi:bmi /var/log/bmi/ bmi:bmi
@CCI-MOC/bmi-breakers let the fights begin!!
Forgot the db should be in /var/lib/bmi/ owned by bmi:bmi. Probably we can move tftpboot also to this folder.
TBH, I did not understand the logic behind /etc/bmi owned by root, when we are creating that file shouldn't we do a chown to bmi:bmi - It is created by us during installation so its safe to assume that it shouldn't have root access. The same should be for tgt unless it needs privilege for root on something, even if that is the case, we should have an entry in /etc/sudoers for bmi user to execute that particular command.
@ravisantoshgudimetla I didn't see a single program till now that has a folder in /etc/ not owned by root and /etc/ typically has config files which are supposed to be edited by humans. If there is a software that will allow a program to edit files in /etc/ then it typically has a special program with the 7th bit set that only edits that file.
The only file I saw in /etc/ not owned by root is the keyring file which is not a conf file.
I googled for adding targets to tgt and I got GitHub projects for iscsi rest apis and all. Then researched on tgt-admin and conf files then realized that tgt-admin simply reads the conf files and executes tgtadm commands when we do --executes. So I felt the right way would be to execute the commands directly ourselves will make it a few ms or ns faster, if we add tgtadm to the /etc/sudoers then we wouldn't need to do sudo also which will make bmi even more secure.
Also @apoorvemohan say that /etc/tgt/ should be root for tgt to work (I didn't test this)
@chemistry-sourabh Rule of thumb again, any software which needs to run as root and then drops it privileges usually have those bits set. For example apache(httpd)(I usually create it with apache user and if it need privilege escalation(for example running on port 80(<1024 owned by root) will set bit again). So it depends on what our software is intended to do. For example, in openstack even if nova.conf is owned by nova, it will work fine as long as nova has privileged access to libvirtd daemon. So, to re-iterate its upto to users to define, which directories you want to be owned by users and by root. (https://www.nixcraft.com/terry-lambert-quote-it-is-not-unixs-job-to-stop-you/82/) - just a quote :)
So you are saying make everything owned by bmi. @apoorvemohan will tgt still work ?
Add on even the keyring should be owned by bmi:bmi to prevent ceph errors
@apoorvemohan will tgt still work ?
like ravi suggested, tgt commands can be added to /etc/sudoers (at the time of installation) so that the bmi user can run those.
