now..when i start syslog-ng with umask 077, i get files generated as 0600 when i start with umask 022, i get files generated with as 0644. i though that perm and dir_perm were set while ignoring umask, this should be noted in the documentation if it uses umask as well.
umask is enforced by the kernel. syslog-ng doesn't use it, it simply issues chmod(file, perm), kernel masks bits found in umask.
On which UNIX and where can I get a copy? ;)
To be honest I never checked this directly (ie kernel source), but here's the relevant part of the Linux kernel source: struct dentry * open_namei(const char * pathname, int flag, int mode) { int acc_mode, error; struct inode *inode; struct dentry *dentry; mode &= S_IALLUGO & ~current->fs->umask; mode |= S_IFREG; or the man page for open: OPEN(2) System calls OPEN(2) mode specifies the permissions to use if a new file is created. It is modified by the process's umask in the usual way: the permissions of the created file are (mode & ~umask).
I have only seen this type of mode enforcement on B1 systems. chmod() calls (except symbolic ones without "ugo" specification) will actually ignore umask settings. open() in turn, will not, and I guess that's why we are seeing what we see :)
you are right, syslog-ng uses simply open with mode set to perm | O_WRONLY.
I'd have to look at the source, but I suspect something with the chmod being wrong. As far as I'm concerned, perm's that were specified explicitely should be in place regardless of the umask. I start all my daemons with 077, just in case they dump temporary stuff (e.g. cores) to disk that I don't want others to read, overwrite, whatever. I still might want to create output files with permissions appropriate to archive files or make them available for other legitimate users.
I may add a chmod() call to enforce perm bits. What do others think? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt