[pkg-firebird-general] Bug#767497: Bug#767497: firebird2.5-super: world writable file in /run after upgrade to jessie

[Damyan Ivanov]

Control: severity -1 important

Hi Holger,

-=| Holger Levsen, 31.10.2014 14:12:52 +0100 |=-
> Package: firebird2.5-super
> Version: 2.5.3.26778.ds4-2
> Severity: serious
> User: debian-qa at lists.debian.org
> Usertags: piuparts
> 
> during a test with piuparts I noticed something odd in your package. It 
> installed fine in wheezy and upgrade fine to jessie too but then this is 
> found:
> 
> From the attached log (scroll to the bottom...):
> 
> 1m25.2s DEBUG: Starting command: ['chroot', 
> '/srv/piuparts.debian.org/tmp/tmp7YWD5y', 
> 'tmp/scripts/pre_remove_50_find_bad_permissions']
> 1m25.3s DUMP: 
>   ERROR: BAD PERMISSIONS
>   -rw-rw-rw- 1 firebird firebird 0 Oct 31 00:50 /run/firebird/2.5/fb_guard
> 
> world writeable, seriously??
> 
> What I find a bit strange is that neither 
> https://piuparts.debian.org/wheezy/source/f/firebird2.5.html nor
> https://piuparts.debian.org/jessie/source/f/firebird2.5.html show this issue 
> however.

Interesting.

I have that file on my system too, with 0666 permissions. However, the 
containing directory looks like this:

$ ls -ld /run/firebird/2.5
drwxrwx--- 2 firebird firebird 80 Oct 31 20:02 /run/firebird/2.5

So I don't think we have an exploitable problem here, since the file 
is not reachable by users not members of the firebird group. Lowering 
severity accordingly.

Still, I agree the permissions need fixing in case the directory 
permissions change in the future.

The code that deals with the lock file is:

src/utilities/guard/guard.cpp:

 148         // get and set the umask for the current process
 149         const ULONG new_mask = 0000;
 150         const ULONG old_mask = umask(new_mask);
 151 
 152         // exclusive lock the file
 153         int fd_guard;
 154         if ((fd_guard = UTIL_ex_lock(GUARD_FILE)) < 0)
 155         {
 156                 // could not get exclusive lock -- some other guardian is running
 157                 if (fd_guard == -2)
 158                         fprintf(stderr, "%s: Program is already running.\n", prog_name);
 159                 exit(-3);
 160         }
 161 
 162         // the umask back to orignal donot want to carry this to child process
 163         umask(old_mask);

The UTIL_ex_lock function creates the file like this:

src/utilities/guard/util.cpp:

 255         // file fd for the opened and locked file
 256         int fd_file = open(expanded_filename.c_str(), O_RDWR | O_CREAT, 0666);


I'll try patching both place to clear the world access bits.


-- dam