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