i noticed something odd when in installed syslog-ng heres my current setup
Linux flatbox 2.4.0-test9 #4 Thu Oct 12 14:03:39 EDT 2000 i686 unknown syslog-ng 1.4.8 (also had problem with 1.4.7)
It seems that syslog-ng is ignoring perm(xxx) in favor of umask. heres the lines from syslog-ng.conf destination macrogenerateddaily { file("/var/log/ng/$HOST/$YEAR$MONTH$DAY/$FACILITY.$PRIORITY" dir_perm(0755) perm(0644)); }; destination macrogeneratedhourly { file("/var/log/ng/$HOST/$YEAR$MONTH$DAY/$FACILITY.$PRIORITY.$HOUR" dir_perm(0755) perm(0644)); }; 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. jon
i noticed something odd when in installed syslog-ng heres my current setup
Linux flatbox 2.4.0-test9 #4 Thu Oct 12 14:03:39 EDT 2000 i686 unknown syslog-ng 1.4.8 (also had problem with 1.4.7)
It seems that syslog-ng is ignoring perm(xxx) in favor of umask. heres the lines from syslog-ng.conf destination macrogenerateddaily { file("/var/log/ng/$HOST/$YEAR$MONTH$DAY/$FACILITY.$PRIORITY" dir_perm(0755) perm(0644)); };
destination macrogeneratedhourly { file("/var/log/ng/$HOST/$YEAR$MONTH$DAY/$FACILITY.$PRIORITY.$HOUR" dir_perm(0755) perm(0644)); };
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. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt
Balazs Scheidler on Tue, Nov 14, 2000 at 11:17:45AM +0100: Hi,
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? ;) 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 :) 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. Greetings, Gregor. -- Gregor Binder <gbinder@sysfive.com> http://www.sysfive.com/~gbinder/ sysfive.com GmbH UNIX. Networking. Security. Applications. Gaertnerstrasse 125b, 20253 Hamburg, Germany TEL +49-40-63647482
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
participants (3)
-
Balazs Scheidler
-
Gregor Binder
-
jon＠dumbo.pobox.com