Reading debian bug #21983,
<URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=21983> one
discover that there might be a security problem creating files in
/tmp/. This also is in conflict with the Linux File Hierarcy Standard.
I propose the following patch to fix the problem. Anyone against it?
- Change qcam lock file name from /tmp/LOCK.qcam.0x<port> to
/var/lock/LCK..qcam.0x<port> to get it more in sync with Linux FHS
and avoid possible security issue with keeping the lock file in
/tmp/.
Index: qcam.c
===================================================================
RCS file: /cvsroot/external/sane/sane-backends/backend/qcam.c,v
retrieving revision 1.6
diff -u -w -r1.6 qcam.c
--- qcam.c 2002/01/11 17:49:09 1.6
+++ qcam.c 2002/03/24 19:03:32
@@ -104,6 +104,23 @@
#include "sane/sanei_config.h"
#define QCAM_CONFIG_FILE "qcam.conf"
+/*
+ * How to lock the qcam parport device.
+ *
+ * According to the FHS,
+ * <URL:http://www.pathname.com/fhs/2.0/fhs-5.5.html>, the proper
+ * directory is "/var/lock", and the proper filename is "LCK..lp#".
+ *
+ * The parport number (lp#) is not available, so that part will have
+ * to be adjusted.
+ */
+#ifndef QCAM_LOCKDIR
+# define QCAM_LOCKDIR "/var/lock"
+#endif /* QCAM_LOCKDIR */
+#ifndef QCAM_LOCKFILE
+# define QCAM_LOCKFILE "LCK..qcam.0x%x"
+#endif /* QCAM_LOCKFILE */
+
/* status bits */
#define NeedRamTable (1 << 1)
#define BlackBalanceInProgress (1 << 6)
@@ -298,7 +315,7 @@
{
char lockfile[128];
- sprintf (lockfile, "/tmp/LOCK.qcam.0x%x", q->port);
+ sprintf (lockfile, QCAM_LOCKDIR "/" QCAM_LOCKFILE, q->port);
q->lock_fd = open (lockfile,
O_WRONLY | O_CREAT | O_EXCL
, 0666);
@@ -362,7 +379,7 @@
return SANE_STATUS_INVAL;
}
#endif
- sprintf (lockfile, "/tmp/LOCK.qcam.0x%x", q->port);
+ sprintf (lockfile, QCAM_LOCKDIR "/" QCAM_LOCKFILE, q->port);
unlink (lockfile);
close (q->lock_fd);
q->lock_fd = -1;
