Bug#611659: cfengine seems to dislike Debian's symlinks [patch]

2011-06-28 Thread Chris Dumont
Hi,

IMO, the problem is that if some things are debianized then the example
file, update.cf, needs to be debianized too. 

With the following patch the example set of files work as expected:

diff -u /usr/share/doc/cfengine3/examples/update.cf \
/etc/cfengine3/update.cf 
--- /usr/share/doc/cfengine3/examples/update.cf 2010-06-09
15:57:14.0 -0700
+++ /etc/cfengine3/update.cf2011-06-28 17:07:25.0 -0700
@@ -30,7 +30,7 @@
 
 files:
 
-  "/var/lib/cfengine3/inputs"
+  "/etc/cfengine3"
 
 perms => u_p("600"),
 copy_from => mycopy("$(master_location)","localhost"),

Cheers,
Chris





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#611659: cfengine seems to dislike Debian's symlinks

2011-05-31 Thread Mike Brodbelt
Seeing the same behavious on my installation. Reversing the direction of
the symlink, so making /var/lib/cfengine3/inputs a real directory and
/etc/cfengine3 a symlink to it seems to fix the problem, while retaining
the desired bahaviour.

Mike



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#611659: cfengine seems to dislike Debian's symlinks

2011-05-17 Thread ishikawa
I also experienced the same problem.

The correct workaround seems to be this:

The symlink /var/lib/cfengine3/inputs has to be a real directory.

E.g.,

   cd /var/lib/cfengine3
   mv inputs inputs.old
   mkdir inputs
   cp /usr/share/doc/cfengine3/examples/* /var/lib/cfengine3/inputs

   * be careful to set the directory permission to of "inputs".
   Usually, root-owned and not world writable should be OK.

env LANG=C ls -l /var/lib/cfengine3

total 180
lrwxrwxrwx 1 root root  9 Apr 13 06:45 bin -> /usr/sbin
-rw--- 1 root root  16384 May 17 15:51 cf_classes.db
drwxr-xr-x 2 root root   4096 May 16 12:20 inputs
lrwxrwxrwx 1 root root 14 Apr 13 06:45 inputs.old -> /etc/cfengine3
drwxr-xr-x 2 root root   4096 May 16 12:15 lastseen
drwxr-xr-x 2 root root   4096 May 16 12:18 masterfiles
drwx-- 2 root root   4096 May 16 12:15 modules
drwxr-xr-x 2 root root   4096 May 17 15:51 outputs
-rw--- 1 root root   8192 May 17 15:50 performance.db
drwx-- 2 root root   4096 May 16 12:15 ppkeys
-rw--- 1 root root 116528 May 17 15:51 promise_summary.log
-rw-r--r-- 1 root root   1024 May 16 12:15 randseed
drwxr-xr-x 2 root root   4096 May 16 12:15 reports
drwxr-xr-x 2 root root   4096 May 17 15:52 state


This wastes /etc/cfengine3. The files under it are not used at all.

The cause:

Obviously, the link /var/lib/cfengine3/inputs was created as a
handy manner to refer to /etc/cfengine3/.

But cfengine3 seems to have a rather peculiar security concern of
using a symlink to refer to the directory where configuration files are stored.
Such a caution is not unexpected for a security-conscious program.
(Still I am a little surprised here since sendmail v8 used to allow the
reference to user-defined programs that are invoked during sendmail run
through a symlink under a protected diretory. cfengine3 seems to take a more
serious attitude re symlinks. That is, this symlink is BELOW a root-owned
world-non-writable directory, and is safe IMHO. But cfengine probably was
never intended to refer to configuration files through a symlink anyway.)

>From /usr/share/doc/cfengine3/README.cfengine3
--- quote begins ---
*) cfengine3 is FHS, that means that, unlike the original, we log in /var/log,
the binaries are located in /usr/sbin and the inputs files are in
/etc/cfengine3; for upstream compatibility we have two symlinks:

/etc/cfengine3 -> /var/lib/cfengine3/inputs
/usr/sbin  -> /var/lib/cfengine3/bin

--- end quote

So the choice of FHS file layout is something to blame until
cfengine3 source file is fixed to allow for *THIS* particular
setup (and NOT others for obvious security reasons).

Oh wait. I just tried to install cfengine3 yesterday, and have not
tested the invocation of various commands through cron entries.
I wonder if /var/lib/cfengine3/bin is suffering from the same problem ???

At least the crontab entries installed by cfengine3 seems to be invoked
every 5 minutes without major ill-effects: but I have yet to configure
cfengine3 to copy various files from the master repository, etc. and so the
relevant commands may not have been invoked really.

Hope this helps.

CI



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#611659: cfengine seems to dislike Debian's symlinks

2011-01-31 Thread Federico Heinz
Package: cfengine3
Version: 3.0.5+dfsg-1

To reproduce:

# aptitude install cfengine3
# cp /usr/share/doc/cfengine3/examples/* /etc/cfengine3
# cfengine-server:/etc/cfengine3# cf-agent -nI
SERIOUS SECURITY ALERT: path race exploited in recursion to/from 
/var/lib/cfengine3/inputs. Not safe for agent to continue - aborting
Received signal 15 (SIGTERM) while doing []

A search for the problem yielded little information, hinting that
cfengine may be taking exception to /var/lib/cfengine3/inputs being
a symbolic link. Cursory inspection of the source code involved in
printing that message seems to imply that it indeed wouldn't like
symlinks (in src/recursion.c):

void CheckLinkSecurity(struct stat *sb,char *name)

{ struct stat security;

Debug("Checking the inode and device to make sure we are where we think we 
are...\n"); 

if (cfstat(".",&security) == -1)
   {
   CfOut(cf_error,"stat","Could not stat directory %s after entering!",name);
   return;
   }

if ((sb->st_dev != security.st_dev) || (sb->st_ino != security.st_ino))
   {
   CfOut(cf_error,"","SERIOUS SECURITY ALERT: path race exploited in recursion 
to/from %s. Not safe for agent to continue - aborting",name);
   HandleSignals(SIGTERM);
   /* Exits */
   }
}

It is not clear to me why cfengine would have such a bad attitude
towards symlinks in its work area. I am also amazed that people seem to
be using cfengine3 on Debian, yet this has gone unreported.

This is running on Squeeze.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org