Bug #134

Permissions on Default Lockfile Make Running oned Under Unprivileged User Impossible

Added by Tres Wong-Godfrey over 8 years ago. Updated almost 8 years ago.

Status:ClosedStart date:08/21/2009
Priority:NormalDue date:
Assignee:Jaime Melis% Done:

0%

Category:Core & System
Target version:Release 1.4
Resolution:fixed Pull request:
Affected Versions:

Description

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.

oned.lockfile.patch Magnifier (105 Bytes) Tres Wong-Godfrey, 08/21/2009 12:29 AM

Associated revisions

Revision 3ca29dbf
Added by Jaime Melis almost 8 years ago

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

History

#1 Updated by Ruben S. Montero about 8 years ago

  • Category set to Core & System
  • Assignee set to Jaime Melis
  • Target version set to Release 1.4

#2 Updated by Jaime Melis about 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 about 8 years ago

Hi Jamie,

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
BIN_LOCATION="/usr/bin"
LIB_LOCATION="/usr/lib/one"
ETC_LOCATION="/etc/one"
LOG_LOCATION="/var/log/one"
VAR_LOCATION="/var/lib/one"
RUN_LOCATION="/var/run/one"
INCLUDE_LOCATION="/usr/include"
SHARE_LOCATION="/usr/share/doc/opennebula"

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.

Regards,
Tres

#4 Updated by Jaime Melis almost 8 years ago

Hi,
actually, the lock file gets created in /var/run/one/ , which is a directory that belongs to the ONE user after applying the chown you pointed out: CHOWN_DIRS="$LOG_LOCATION $VAR_LOCATION $RUN_LOCATION".

Does it make sense now?

#5 Updated by Tres Wong-Godfrey almost 8 years ago

Hi Jamie,

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.

Regards,
Tres

#6 Updated by Jaime Melis almost 8 years ago

  • Resolution changed from worksforme to fixed

Hi Tres,

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.

Also available in: Atom PDF