Permissions on Default Lockfile Make Running oned Under Unprivileged User Impossible
|Assignee:||Jaime Melis||% Done:|
|Category:||Core & System|
|Target version:||Release 1.4|
By default the lockfile for oned is set to /var/lock/one when installing in system wide mode. Since /var/lock is not writable by unprivileged users, it is impossible to start oned.
Suggested fix is to create a /var/lock/one/ directory owned by the user/group set as one admin and place the lock file in this directory as /var/lock/one/one. I've attached a simple patch to affect this fix.
Moved the lock in system-wide installation mode. Fixed occi-server and econe-server scripts for system-wide installations #134
git-svn-id: http://svn.opennebula.org/one/branches/one-1.4@931 3034c82b-c49b-4eb3-8279-a7acafdc01c0
#2 Updated by Jaime Melis over 8 years ago
- Status changed from New to Closed
- Resolution set to worksforme
We have not been able to reproduce the bug. When installed in system-wide mode the /var/lock/one file is succesfully chown'd to the user referred to by the -u flag in the install.sh, therefore that user can start oned without any problems.
#3 Updated by Tres Wong-Godfrey over 8 years ago
Thanks for checking into this. I took a look at install.sh from the latest RC and here's what I see for install locations:
if [ -z "$ROOT" ] ; then
Notice that there is no reference to a lock file at all.
If I grep -i "lock" i get nothing out of install.sh.
In the install.sh script I have, the CHOWN_DIRS variable is defined:
CHOWN_DIRS="$LOG_LOCATION $VAR_LOCATION $RUN_LOCATION"
So, I'm not sure if I'm overlooking something, or if there's a different install script that I'm not using.
Thanks again for your time and your help.
#5 Updated by Tres Wong-Godfrey about 8 years ago
The version of OpenNebula I have uses /var/lock/one for the lock file. Check out line 118 of one-1.3.90/src/nebula/oned.cc:
lockfile = "/var/lock/one";
If the lock file is supposed to be under /var/run, then it would appear that oned.cc needs to be updated to reflect that.
Thanks again for your time.
#6 Updated by Jaime Melis about 8 years ago
- Resolution changed from worksforme to fixed
You were very right. The reason why it was working for us is because in debian based distributions:
(debian) $ ls -ld /var/lock
drwxrwxrwt 3 root root 4096 2009-12-02 11:45 /var/lock
while in redhat/fedora:
(redhat/fedora) # ls -ld /var/lock
drwxrwxr-x 5 root lock 4096 Dec 2 12:46 /var/lock
So in debian based distributions the oneadmin user had permissions to write in /var/lock.
In any case we considered your suggestion to be the best option here, so we have commited the patch you attached and applied a few extra modifications for everything to be coherent.
Thank you very much for your great feedback.