[torqueusers] Bug in chk_file_sec: Relative Symlinks

Eric J. Bowersox ericb at aspsys.com
Wed Sep 22 15:48:31 MDT 2004

I've discovered a bug in the way that Torque's library routine
chk_file_sec handles relative symlinks.  This manifested itself in a
rather striking fashion on my workstation, where my "/var" is actually a
symlink to "x/var" (/x being a separate filesystem).

When pbs_server starts up, it attempts to run chk_file_sec on
/var/spool/PBS/server_priv/jobs (since /var/spool/PBS was defined as the
home directory for the server).  As the function worked its way up the
directory path, it eventually got to /var, and read it as a symlink. 
Unfortunately, it created the full pathname, not as "/x/var", but as
"/var/x/var".  It then tried to check this path, working its way up to
/var, where it read the symlink, and assembled the name "/var/x/var",
and...you get the idea.  Eventually, of course, it segfaulted.

The attached patch eliminates that problem, and gets pbs_server running
properly for me.  (Apologies for the attachment, but my mail client was
wrapping lines when I tried to include the file directly as text...)

Eric J. Bowersox, Software Engineer     Aspen Systems, Inc.
<ericb at aspsys.com>                      3900 Youngfield Street
Tel: +01 303 431 4606 x113              Wheat Ridge, CO  80033, USA
Fax: +01 303 431 7196                   <http://www.aspsys.com>
-------------- next part --------------
--- src/lib/Liblog/chk_file_sec.c.original	2004-09-22 15:04:44.000000000 -0600
+++ src/lib/Liblog/chk_file_sec.c	2004-09-22 15:24:15.000000000 -0600
@@ -163,7 +163,11 @@
 		if (*symlink == '/') {
 			return (chk_file_sec(symlink,isdir,sticky,disallow,fullpath));
 		} else {
-			(void)strcat(shorter, "/");
+	    		(void)strcpy(shorter, path);
+	    		pc  = strrchr(shorter, (int)'/');
+			if (pc != (char*)0) {
+				*(pc+1) = '\0';
+			}
 			(void)strcat(shorter, symlink);
 			return (chk_file_sec(shorter,isdir,sticky,disallow,fullpath));

More information about the torqueusers mailing list