Running a process as background service results in exception

Question

Following piece of code

try {


        String          fileName = "/var/log/syslog";
        File            myFile   = new File(fileName);
        FileInputStream myStream = null;

        System.out.println("canRead()  returns " + myFile.canRead ());
        System.out.println("canWrite() returns " + myFile.canWrite());

        myStream = new FileInputStream(myFile);
        myStream.close();
    }
    catch (FileNotFoundException e)
    {
        System.out.println("FileNotFoundException: " + e);
    }
    catch (IOException e)
    {
        System.out.println("IOException: " + e);
    }

throws

java.io.FileNotFoundException: /var/log/syslog (Permission denied)

when run as a background service

sudo start server

but succeeds when run as a foreground task

exec bin/server.sh

The file exists:

niru@node2:~$ ls -l /var/log/syslog
-rw-r----- 1 syslog adm 616642 Sep  6 15:59 /var/log/syslog

The niru userid has read access to the file:

 niru@node2:~$ id -a niru
 uid=2001(niru) gid=2001(niru) groups=2001(niru),4(adm),27(sudo)
 niru@node2:~$ head -3 /var/log/syslog
 Aug  1 15:47:57 node kernel: imklog 5.8.6, log source = /proc/kmsg started.
 Aug  1 15:47:57 node rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="535" x-info="http://www.rsyslog.com"] start
 Aug  1 15:47:57 node rsyslogd: rsyslogd's groupid changed to 103

Can anyone let me know what would be the reason for this?

Answer 1

This permissions issue because the credentials of the user running the service on a Debian distro are not the same as the credentials of the user.

For example, when logged in as the 'niru' userid, the 'id -a' command returns this output:

niru@node2:~$ id -a
uid=2001(niru) gid=2001(niru) groups=2001(niru),4(adm),27(sudo)

In the context of the service process, the same 'id -a' command returns:

uid=2001(niru) gid=2001(niru) groups=2001(niru)

So, in the service context, the niru userid does not have permissions to read the /var/log/syslog file.

This bug in Upstart is documented here: https://bugs.launchpad.net/upstart/+bug/812870

Adding the setgid parameter to the service startup file resolved the issue.

Answer 2

By running sudo start server the process is no longer running as the user niru so no longer has access to the the syslog file.