Re: BIND 9.4.x vs 9.6.x - pid-file check and creation
Mark Andrews wrote: Looking at the publically available parts of SunSolve there are at least bug reports about it. Requires Support Contract tmp_mkdir()/xmemfs_mkdir() inconsistent with other xxxfs_mkdir() functions. | Open in a new window bug 6253984 http://sunsolve.sun.com/search/document.do?assetkey=1-1-6253984-1 - Sep 10, 2007 FYI this has been fixed in OpenSolaris, alas it has not been fixed in Solaris 9 or 10 and currently there are no plans to do so. Requires Support Contract tmp_mkdir()/xmemfs_mkdir() inconsistent with other xxxfs_mkdir() functions. | Open in a new window bug 2152581 http://sunsolve.sun.com/search/document.do?assetkey=1-1-2152581-1 - Sep 10, 2007 This is the Solaris 10 reference, its closed (hence no plans to fix). With sufficient justification it could be re-opened. Stace I don't have a copy of the POSIX standard that covers mkdir(2) to see what it has to say about it. Historically however EACCES on search failure, EEXIST if the file/directory exists, then EACCES on parent directory write permissions was the error determination order. Mark ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.4.x vs 9.6.x - pid-file check and creation
In message 4981c105.8080...@sun.com, Stacey Jonathan Marshall writes: Mark Andrews wrote: Looking at the publically available parts of SunSolve there are at least bug reports about it. Requires Support Contract tmp_mkdir()/xmemfs_mkdir() inconsistent with othe r xxxfs_mkdir() functions. | Open in a new window bug 6253984 http://sunsolve.sun.com/search/document.do?assetkey=1-1-6253984-1 - Sep 10, 2007 FYI this has been fixed in OpenSolaris, alas it has not been fixed in Solaris 9 or 10 and currently there are no plans to do so. Requires Support Contract tmp_mkdir()/xmemfs_mkdir() inconsistent with othe r xxxfs_mkdir() functions. | Open in a new window bug 2152581 http://sunsolve.sun.com/search/document.do?assetkey=1-1-2152581-1 - Sep 10, 2007 This is the Solaris 10 reference, its closed (hence no plans to fix). With sufficient justification it could be re-opened. The problem isn't that you can't work around it. The problem is that every application that calls mkdir(2) or mkdir will eventually discovery it the hard way by having something break that shouldn't. The net cost involved will far exceed the cost to fix. I would argue that it already has past that point. I programed for the expected error behaviour and did not get it. Error behavior that goes back to the initial creation of the open(2) system call. That the error heirarchy on all file system system calls is access, existance, write. I learn't about this well before POSIX was even thought about. I called mkdir(2) knowing that I would effectively get the stat(2) call for free. Now I need to call stat(2) then call mkdir(2) on ENOENT to work around this bug. Every programer in the world that has worked with mkdir(2) should know what I knew. We don't do looking for gotcha's in really on system calls. We just program for the known interface. I would ask that Sun re-think this decision not to fix the bug. Mark Stace I don't have a copy of the POSIX standard that covers mkdir(2) to see what it has to say about it. Historically however EACCES on search failure, EEXIST if the file/directory exists, then EACCES on parent directory write permissions was the error determination order. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.4.x vs 9.6.x - pid-file check and creation
In article glp3rc$23p...@sf1.isc.org, Jan Arild =?iso-8859-1?Q?Lindstr=F8m?= j...@telenor.net wrote: Hi, ah, of course. I did not think about it as a Solaris bug. I patched BIND 9.6.0-P1 os.c code so it first checks for the diretory before it tries the fast approach of just running mkdir. And that of course works fine. But, since I do not want to run a self-patch BIND in production, I will instead run with pid-file /var/run/named/named/named.pid and be happy with that. Just wondering. Since /var/run is a swap (memory) based file system, do you have to recreate those directories on each reboot? Thanks Jan Arild Lindstr At 15:35 27/01/2009, Mark Andrews wrote: Looking at the publically available parts of SunSolve there are at least bug reports about it. Requires Support Contract tmp_mkdir()/xmemfs_mkdir() inconsistent with oth= er xxxfs_mkdir() functions. | Open in a new window bug 6253984 http://sunsolve.sun.com/search/document.do?assetkey=3D1-1-6253984-1 - Sep = 10, 2007 = Requires Support Contract tmp_mkdir()/xmemfs_mkdir() inconsistent with oth= er xxxfs_mkdir() functions. | Open in a new window bug 2152581 http://sunsolve.sun.com/search/document.do?assetkey=3D1-1-2152581-1 - Sep = 10, 2007 = I don't have a copy of the POSIX standard that covers mkdir(2) to see what it has to say about it. Historically however EACCES on search failure, EEXIST if the file/directory exists, then EACCES on parent directory write permissions was the error determination order. Mark -- = Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Tom Schulz sch...@adi.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.4.x vs 9.6.x - pid-file check and creation
At 09:33 26/01/2009, Mark Andrews wrote:
In message 200901260742.n0q7gjqn029...@mail46.nsc.no, Jan Arild =?iso-8859-1?
Q?Lindstr=F8m?= writes:
Hi,
I was going to upgrade from BIND 9.4.3 to BIND 9.6.0-P1, but run into a =
strange bug in BIND 9.6.0-P1.
Exact same config for 9.4.3 and 9.6.0-P1, only added new to files that =
are written to (namednew.log, confignew.log and namednew.pid).
OS: Solaris 10.
Using:
pid-file /var/run/named/namednew.pid;
.. result in the following:
namednew.log:
26-Jan-2009 08:14:22.723 general: couldn't mkdir /var/run/named/namednew.pi=
d': Permission denied
26-Jan-2009 08:14:22.728 general: exiting (due to early fatal error)
The log message should say couldn't mkdir /var/run/named.
The wrong path is being logged.
You either need to create /var/run/named with appropriate
permissions so that named can write to it or change /var/run's
It does exists as you can see from the ls output I included. And named is
owner of it and hence have full permissions on it (/var/run/named/).
Problem is that Solaris returnes EACCESS and not EEXISTS. So just running mkdir
to check if a directory exists does not work on Solaris. One gets an EACCES and
the
code fails.
permissions so that named can create /var/run/named.
Named will continue if mkdir(/var/run/named) returns EEXISTS.
Wich it will not on Solaris if you do not have the perm to create it, even
though it
exists and you have full perm on it.
?
Mark
/*
* Make the containing directory if it doesn't exist.
*/
slash = strrchr(pidfile, '/');
if (slash != NULL slash != pidfile) {
*slash = '\0';
mode = S_IRUSR | S_IWUSR | S_IXUSR; /* u=rwx */
mode |= S_IRGRP | S_IXGRP; /* g=rx */
mode |= S_IROTH | S_IXOTH; /* o=rx */
n = mkdir(pidfile, mode);
if (n == -1 errno != EEXIST) {
isc__strerror(errno, strbuf, sizeof(strbuf));
(*report)(couldn't mkdir %s': %s, filename,
strbuf);
free(pidfile);
pidfile = NULL;
return;
}
*slash = '/';
}
BIND 9.6.0-P1 truss.out:
--CUT--
25123/65: stat(/dev/urandom, 0x79D0FA00)=3D 0
25123/65: open(/dev/urandom, O_RDONLY|O_NONBLOCK) =3D 9
25123/65: fcntl(9, F_GETFL) =3D 8320
25123/65: fcntl(9, F_SETFL, FOFFMAX|FNONBLOCK)=3D 0
25123/65: setgid(21) =3D 0
25123/65: setuid(21) =3D 0
25123/65: access(., W_OK) =3D 0
25123/65: open(/var/log/namednew.log, O_WRONLY|O_APPEND|O_CREAT, 06=
66) =3D 10
25123/65: lseek(10, 0, SEEK_END) =3D 332
25123/65: close(10) =3D 0
25123/65: open(/var/log/confignew.log, O_WRONLY|O_APPEND|O_CREAT, 0=
666) =3D 10
25123/65: lseek(10, 0, SEEK_END) =3D 0
25123/65: close(10) =3D 0
25123/65: mkdir(/var/run/named, 0755) Err#13 EACC=
ES [ALL]
25123/65: stat(/var/log/namednew.log, 0x79D0F3C0) =3D 0
25123/65: open(/var/log/namednew.log, O_WRONLY|O_APPEND|O_CREAT, 06=
66) =3D 10
25123/65: lseek(10, 0, SEEK_END) =3D 332
25123/65: fstat(10, 0x79D0E540) =3D 0
25123/65: fstat(10, 0x79D0E410) =3D 0
25123/65: ioctl(10, TCGETA, 0x79D0E47C) Err#25 ENOT=
TY
25123/65: write(10, 0x10502E754, 97) =3D 97
25123/65: 2 6 - J a n - 2 0 0 9 0 8 : 1 4 : 2 2 . 7 2 3 g e n =
e r a l
25123/65: : c o u l d n ' t m k d i r / v a r / r u n / n a =
m e d /
25123/65: n a m e d n e w . p i d ' : P e r m i s s i o n d e =
n i e d
25123/65: \n
25123/65: write(10, 0x10502E754, 69) =3D 69
25123/65: 2 6 - J a n - 2 0 0 9 0 8 : 1 4 : 2 2 . 7 2 8 g e n =
e r a l
25123/65: : e x i t i n g ( d u e t o e a r l y f a t a =
l e r
25123/65: r o r )\n
25123/65: _exit(1)
It fails because it tries to just create the /var/run/named directory inste=
ad
of cheking if the directory exist and if it can write to it. =
ns12(root) named 515# ls -la /var/run/named
total 40
drwxr-s---4 namednamed 307 Jan 26 06:51 ./
drwxr-xr-x7 root sys 1285 Jan 26 00:52 ../
-rw-r--r--1 namednamed 6 Jan 26 06:41 named.pid
So /var/run/named
Re: BIND 9.4.x vs 9.6.x - pid-file check and creation
At 22:41 26/01/2009, Mark Andrews wrote:
In message 200901260955.n0q9tnvm010...@mail43.nsc.no, Jan Arild =?iso-8859-1?
Q?Lindstr=F8m?= writes:
At 09:33 26/01/2009, Mark Andrews wrote:
In message 200901260742.n0q7gjqn029...@mail46.nsc.no, Jan Arild=
=3D?iso-8859-1?
Q?Lindstr=3DF8m?=3D writes:
=20
Hi,
=20
I was going to upgrade from BIND 9.4.3 to BIND 9.6.0-P1, but run into a =
=3D
=20
strange bug in BIND 9.6.0-P1.
=20
Exact same config for 9.4.3 and 9.6.0-P1, only added new to files that=
=3D
=20
are written to (namednew.log, confignew.log and namednew.pid).
=20
OS: Solaris 10.
=20
Using:
pid-file /var/run/named/namednew.pid;
=20
.. result in the following:
=20
namednew.log:
26-Jan-2009 08:14:22.723 general: couldn't mkdir=
/var/run/named/namednew.pi=3D
d': Permission denied
26-Jan-2009 08:14:22.728 general: exiting (due to early fatal error)
The log message should say couldn't mkdir /var/run/named.
The wrong path is being logged.
You either need to create /var/run/named with appropriate
permissions so that named can write to it or change /var/run's
It does exists as you can see from the ls output I included. And named=
is
owner of it and hence have full permissions on it (/var/run/named/).
Problem is that Solaris returnes EACCESS and not EEXISTS. So just running=
mkdir=20
to check if a directory exists does not work on Solaris. One gets an EACCES=
and the=20
code fails.
What are all of the permissions involved as it should work
as demonstrated by the test below.
thing1:marka 21:31 {109} % mkdir /foo
mkdir: Failed to make directory /foo; Permission denied
thing1:marka 21:31 {110} % mkdir /tmp
mkdir: Failed to make directory /tmp; File exists
thing1:marka 21:31 {111} % uname -a
SunOS thing1 5.10 Generic_120011-14 sun4u sparc SUNW,Ultra-80
thing1:marka 21:33 {112} %
e.g.
ls -ld / /var /var/run /var/run/named
SunOS ns10.nsc.no 5.10 Generic_137111-07 sun4v sparc SUNW,Sun-Fire-T200
-bash-3.00$ id
uid=21(named) gid=21(named)
-bash-3.00$ ls -ld / /var /var/run /var/run/named /var/run/named-test
drwxr-sr-x 32 root root1024 Jan 27 07:07 /
drwxr-xr-x 47 root sys 1024 Jul 21 2008 /var
drwxr-sr-x 8 root root1216 Jan 27 07:07 /var/run
drwxr-s--- 3 namednamed245 Jan 26 14:44 /var/run/named
drwxrwsr-x 2 root root 117 Jan 27 07:07 /var/run/named-test
-bash-3.00$ mkdir / /var /var/run /var/run/named /var/run/named-test
mkdir: Failed to make directory /; File exists
mkdir: Failed to make directory /var; File exists
mkdir: Failed to make directory /var/run; File exists
mkdir: Failed to make directory /var/run/named; Permission denied
mkdir: Failed to make directory /var/run/named-test; Permission denied
I added /var/run/named-test as a test with root:root as owner.
This is strange.
ns10(root) run 509# getfacl /var
# file: /var
# owner: root
# group: sys
user::rwx
group::r-x #effective:r-x
mask:r-x
other:r-x
ns10(root) run 510# getfacl /var/run
# file: /var/run
# owner: root
# group: root
user::rwx
group::r-x #effective:r-x
mask:rwx
other:r-x
ns10(root) run 511# getfacl /var/run/named
# file: /var/run/named
# owner: named
# group: named
user::rwx
group::r-x #effective:r-x
mask:rwx
other:---
Same thing happens on a new Soalaris 10 also, where I just created the
diretory:
tproxy(root) / 499# mkdir /var/run/named
tproxy(root) / 505# su - named
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
-bash-3.00$ ls -ld / /var /var/run /var/run/named
drwxr-sr-x 33 root root1536 Jan 27 07:14 /
drwxr-xr-x 30 root sys 512 Dec 2 15:59 /var
drwxr-xr-x 8 root sys 1374 Jan 27 07:14 /var/run
drwxrwxr-x 2 root root 117 Jan 27 07:14 /var/run/named
-bash-3.00$
-bash-3.00$ mkdir / /var /var/run /var/run/named
mkdir: Failed to make directory /; File exists
mkdir: Failed to make directory /var; File exists
mkdir: Failed to make directory /var/run; File exists
mkdir: Failed to make directory /var/run/named; Permission denied
It happens on Solaris 9 also:
safe(root) jal 1225# mkdir /var/run/named
safe(root) jal 1226# su - named
Sun Microsystems Inc. SunOS 5.9 Generic May 2002
-bash-3.00$ ls -ld / /var /var/run /var/run/named
drwxr-sr-x 88 root root3072 Jan 27 07:14 /
drwxr-xr-x 39 root sys 1024 Oct 14 10:34 /var
drwxr-sr-x 8 root root1304 Jan 27 07:18 /var/run
drwxr-sr-x 2 root root 117 Jan 27 07:18 /var/run/named
-bash-3.00$ mkdir / /var /var/run /var/run/named
mkdir: Failed to make directory ; No such file or directory
BIND 9.4.x vs 9.6.x - pid-file check and creation
Hi, I was going to upgrade from BIND 9.4.3 to BIND 9.6.0-P1, but run into a strange bug in BIND 9.6.0-P1. Exact same config for 9.4.3 and 9.6.0-P1, only added new to files that are written to (namednew.log, confignew.log and namednew.pid). OS: Solaris 10. Using: pid-file /var/run/named/namednew.pid; .. result in the following: namednew.log: 26-Jan-2009 08:14:22.723 general: couldn't mkdir /var/run/named/namednew.pid': Permission denied 26-Jan-2009 08:14:22.728 general: exiting (due to early fatal error) BIND 9.6.0-P1 truss.out: --CUT-- 25123/65: stat(/dev/urandom, 0x79D0FA00)= 0 25123/65: open(/dev/urandom, O_RDONLY|O_NONBLOCK) = 9 25123/65: fcntl(9, F_GETFL) = 8320 25123/65: fcntl(9, F_SETFL, FOFFMAX|FNONBLOCK)= 0 25123/65: setgid(21) = 0 25123/65: setuid(21) = 0 25123/65: access(., W_OK) = 0 25123/65: open(/var/log/namednew.log, O_WRONLY|O_APPEND|O_CREAT, 0666) = 10 25123/65: lseek(10, 0, SEEK_END) = 332 25123/65: close(10) = 0 25123/65: open(/var/log/confignew.log, O_WRONLY|O_APPEND|O_CREAT, 0666) = 10 25123/65: lseek(10, 0, SEEK_END) = 0 25123/65: close(10) = 0 25123/65: mkdir(/var/run/named, 0755) Err#13 EACCES [ALL] 25123/65: stat(/var/log/namednew.log, 0x79D0F3C0) = 0 25123/65: open(/var/log/namednew.log, O_WRONLY|O_APPEND|O_CREAT, 0666) = 10 25123/65: lseek(10, 0, SEEK_END) = 332 25123/65: fstat(10, 0x79D0E540) = 0 25123/65: fstat(10, 0x79D0E410) = 0 25123/65: ioctl(10, TCGETA, 0x79D0E47C) Err#25 ENOTTY 25123/65: write(10, 0x10502E754, 97) = 97 25123/65: 2 6 - J a n - 2 0 0 9 0 8 : 1 4 : 2 2 . 7 2 3 g e n e r a l 25123/65: : c o u l d n ' t m k d i r / v a r / r u n / n a m e d / 25123/65: n a m e d n e w . p i d ' : P e r m i s s i o n d e n i e d 25123/65: \n 25123/65: write(10, 0x10502E754, 69) = 69 25123/65: 2 6 - J a n - 2 0 0 9 0 8 : 1 4 : 2 2 . 7 2 8 g e n e r a l 25123/65: : e x i t i n g ( d u e t o e a r l y f a t a l e r 25123/65: r o r )\n 25123/65: _exit(1) It fails because it tries to just create the /var/run/named directory instead of cheking if the directory exist and if it can write to it. ns12(root) named 515# ls -la /var/run/named total 40 drwxr-s---4 namednamed 307 Jan 26 06:51 ./ drwxr-xr-x7 root sys 1285 Jan 26 00:52 ../ -rw-r--r--1 namednamed 6 Jan 26 06:41 named.pid So /var/run/named exists and is fully writable by user named. User named should of course not be able to crate diretories below /var/run. Especially since many other things on Solaris 10 uses that directory also. If I use: pid-file /var/run/named/named/namednew.pid; ... everything works fine, since it now can run mkdir without getting EACCES. Instead it gets EEXIST and is OK with that. BIND 9.6.0-P1 truss.out: --CUT-- 25404/65: stat(/dev/urandom, 0x79D0FA00)= 0 25404/65: open(/dev/urandom, O_RDONLY|O_NONBLOCK) = 9 25404/65: fcntl(9, F_GETFL) = 8320 25404/65: fcntl(9, F_SETFL, FOFFMAX|FNONBLOCK)= 0 25404/65: setgid(21) = 0 25404/65: setuid(21) = 0 25404/65: access(., W_OK) = 0 25404/65: open(/var/log/namednew.log, O_WRONLY|O_APPEND|O_CREAT, 0666) = 10 25404/65: lseek(10, 0, SEEK_END) = 498 25404/65: close(10) = 0 25404/65: open(/var/log/confignew.log, O_WRONLY|O_APPEND|O_CREAT, 0666) = 10 25404/65: lseek(10, 0, SEEK_END) = 0 25404/65: close(10) = 0 25404/65: mkdir(/var/run/named/named, 0755) Err#17 EEXIST 25404/65: stat(/var/run/named/named/namednew.pid, 0x79D0F980) Err#2 ENOENT 25404/65: unlink(/var/run/named/named/namednew.pid) Err#2 ENOENT 25404/65: open(/var/run/named/named/namednew.pid, O_WRONLY|O_CREAT|O_EXCL, 0644) = 10 25404/65: fcntl(10, F_GETFD, 0x01A4) = 0 25404/65: getpid()= 25404 [25403] 25404/65: fstat(10, 0x79D0E9D0) = 0 25404/65: fstat(10, 0x79D0E8A0) = 0 25404/65:
