working directory not writable

Mark Andrews Mark_Andrews at isc.org
Wed Jul 16 22:22:52 UTC 2008


> I just read through a recent discussion about this
> problem(?), which I also have on my system, but saw
> mostly arguments about the merits of various OSes
> and configurations.  I didn't see anything about the
> actual issue itself, so I'm going to ask again, and
> begin with the results of my own experiments...
> 
> When I upgraded to the latest BIND9, I discovered
> that a new check had been added that was causing
> 
> 'the working directory is not writable'
> 
> to be logged when named started.  Within a minute or
> two though, named started /writing/ to files in that
> directory anyway (well, their content and timestamps
> changed, I /think/ that qualifies as writing).
> 
> Curios about the problem, I added some diagnostics to
> the code where the error was being logged, like this
> (from around line 2953 in bin/named/server.c):
> 
>   if (access(".", W_OK) != 0) {
>       char pwd[256];
>       char err[256];
>       strcpy(err,strerror(errno));
>       isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
>          NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
>          "the working directory (%s) is not writable [%s] by u%d g%d",
>          getcwd(pwd,sizeof(pwd)), err, geteuid(), getegid());
>   }
> 
> (I know it isn't pretty, but it is only temporary)
> 
> I was not quite prepared for what was logged:
> 
>    the working directory (/var/named) is not writable [Permission
>    denied] by u0 g0
> 
> (sorry for the wrap)
> 
> Other info:
> 
> >From 'grep named /etc/passwd':
> 
>   named:x:25:25:Named:/var/named:/sbin/nologin
> 
> from 'ls -l /var | grep named':
> 
>   drwxr-x---  4 named named 4096 Jul  2 21:10 named
> 
> from 'ls -l `which named`' (run as root):
> 
>   -rwxr-xr-x 2 named named 4679248 Jul  9 10:42 /usr/local/sbin/named
> 
> I also wrote a test program that did the same access() call
> and printed the results after assuming named's identity, both
> with setegid/seteuid and setgid/setuid, but it also succeeds
> (and displays the expected uid/gid in the message).
> 
> Lastly, I found that the 'not writable' message goes away when
> I made the directory /group/ writable (remember it is owned by
> named.named already).
> 
> What I'm really curios about is:
> 
> (a) If the effective uid/gid is 0 (root), how can the access()
>     call be resulting in "access denied"?
> 
> (b) If write access is *NOT* available, how is named updating
>     the files contained therein?
> 
> (c) Why doesn't it appear that named is running under the named
>     uid when the access() call fails?
> 
> (d) If named was actually running under the named uid, then why
>     was it denied write access to a directory owned by named
>     that had permissions of drwxr-x--- ?
> 
> -- 
> Steve Vallière | mailto:bind9 at e-visions.com

	Under linux named drops root's extra capabilities.
	You also need  to look a SELinux.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org


More information about the bind-users mailing list