Re: CVS commit: src/external/bsd/bind/dist/bin/named

2009-04-24 Thread Perry E. Metzger

chris...@zoulas.com (Christos Zoulas) writes:
> And I don't really see the need to make the whole namedb directory owned
> by named. Even the pri directory does not need to be writable by named.

The only time named really needs to write to the config dir is for
dynamic update. The only other time it writes is to dump a debugging
file -- the latter is supposed to be done in /var/tmp though.


Perry
-- 
Perry E. Metzgerpe...@piermont.com


Re: CVS commit: src/etc/rc.d

2009-04-24 Thread Christos Zoulas
In article <87k55c4jkd@snark.cb.piermont.com>,
Perry E. Metzger  wrote:
>
>Christos Zoulas  writes:
>> Module Name: src
>> Committed By:christos
>> Date:Wed Apr 22 18:27:03 UTC 2009
>>
>> Modified Files:
>>  src/etc/rc.d: named
>>
>> Log Message:
>> Adjust for new default location of the pid file.
>
>Seems kind of weird to have stuff in /var/run/named/named.pid -- what's
>the point?

2486.   [func]  The default locations for named.pid and lwresd.pid
are now /var/run/named/named.pid and
/var/run/lwresd/lwresd.pid respectively.

This allows the owner of the containing directory
to be set, for "named -u" support, and allows there
to be a permanent symbolic link in the path, for
"named -t" support.  [RT #18306]

christos



re: CVS commit: src/external/bsd/bind/dist/bin/named

2009-04-24 Thread Christos Zoulas
On Apr 25,  1:31am, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/external/bsd/bind/dist/bin/named

|Perhaps you are confusing this directory with /var/chroot/named/etc/namedb?
| 
| i'm saying that named should be configured to have this dir as
| the cwd and then the permissions check you removed will pass.

I take it that "this dir" means /var/chroot/named/etc/namedb, then perhaps
yes. I agree although not 100%, since my current tree looks like:

$ ls -al /var/chroot/named/etc/namedb
drwxr-xr-x  6 root   wheel   512 Jul 19  2008 ./
drwxr-xr-x  4 root   wheel   512 Jul 19  2008 ../
-rw-r--r--  1 root   wheel   259 Dec  3  2004 127
-r--r--r--  1 root   wheel  1525 May 30  2008 Makefile
drwxr-xr-x  2 root   wheel   512 Feb 15  2006 RCS/
drwxr-xr-x  2 named  named   512 Nov  4  2004 cache/
drwxr-xr-x  3 named  named   512 Apr 23  2007 pri/
-r--r--r--  1 root   wheel  2517 Nov  1  2007 root.cache
drwxr-xr-x  2 named  named  3584 Apr 24 11:40 sec/

[my primary zones are in pri and my secondary zones in sec]

And I don't really see the need to make the whole namedb directory owned
by named. Even the pri directory does not need to be writable by named.

| the bug here is that your named is running chrooted an unprived
| in /var/chroot/named with cwd, not the etc/namedb subdir.

Well, it needs to chroot there, but then it could chdir() to etc/namedb.
I will look if this is feasible when I get some cycles. For now commenting
out the test is the same behavior that we had in the previous versions
of named.

christos


re: CVS commit: src/external/bsd/bind/dist/bin/named

2009-04-24 Thread matthew green

   In article <22061.1240544...@splode.eterna.com.au>,
   matthew green   wrote:
   >   
   >   Modified Files:
   >src/external/bsd/bind/dist/bin/named: server.c
   >   
   >   Log Message:
   >   Don't log if "." is not writable. In the chrooted environment this is
   >   "/var/chroot/named", and there is no reason whatsoever for this to be
   >   writable!
   >
   >
   >this seems bogus to me.
   >
   >this check seems to be about making sure it can write secondary
   >files.  it's a good check.
   >
   >
   >for my named chroot setup a9hich i've been using since before
   >both netbsd or bind-proper had them, but using the same basic
   >technique of named user/group & chroot), i kept named chdiring
   >into, eg, /var/chroots/named/etc/namedb and that dir was
   >writable, but the toplevel chroot dir was not.
   >
   >please restore this check and fix the usage.
   >
   >
   
   I don't think you are right here:
   
   $ ls -l /var/chroot/named/
   total 8
   drwxr-xr-x  2 root  wheel  512 Jun  3  2005 dev/
   drwxr-xr-x  4 root  wheel  512 Oct  2  2005 etc/
   drwxr-xr-x  3 root  wheel  512 May 22  2005 usr/
   drwxr-xr-x  4 root  wheel  512 May 22  2005 var/
   
   This is like root, and I have security issues changing the permissions there.
   Named has no business having write access there.

i'm not saying change this.
   
   Perhaps you are confusing this directory with /var/chroot/named/etc/namedb?

i'm saying that named should be configured to have this dir as
the cwd and then the permissions check you removed will pass.

the bug here is that your named is running chrooted an unprived
in /var/chroot/named with cwd, not the etc/namedb subdir.
   

.mrg.


Re: CVS commit: src/external/bsd/bind/dist/bin/named

2009-04-24 Thread Christos Zoulas
In article <22061.1240544...@splode.eterna.com.au>,
matthew green   wrote:
>   
>   Modified Files:
>   src/external/bsd/bind/dist/bin/named: server.c
>   
>   Log Message:
>   Don't log if "." is not writable. In the chrooted environment this is
>   "/var/chroot/named", and there is no reason whatsoever for this to be
>   writable!
>
>
>this seems bogus to me.
>
>this check seems to be about making sure it can write secondary
>files.  it's a good check.
>
>
>for my named chroot setup a9hich i've been using since before
>both netbsd or bind-proper had them, but using the same basic
>technique of named user/group & chroot), i kept named chdiring
>into, eg, /var/chroots/named/etc/namedb and that dir was
>writable, but the toplevel chroot dir was not.
>
>please restore this check and fix the usage.
>
>

I don't think you are right here:

$ ls -l /var/chroot/named/
total 8
drwxr-xr-x  2 root  wheel  512 Jun  3  2005 dev/
drwxr-xr-x  4 root  wheel  512 Oct  2  2005 etc/
drwxr-xr-x  3 root  wheel  512 May 22  2005 usr/
drwxr-xr-x  4 root  wheel  512 May 22  2005 var/

This is like root, and I have security issues changing the permissions there.
Named has no business having write access there.

Perhaps you are confusing this directory with /var/chroot/named/etc/namedb?

christos



Re: CVS commit: src/sys/fs/tmpfs

2009-04-24 Thread Antti Kantee
On Sat Apr 11 2009 at 20:42:59 +, Andrew Doran wrote:
> On Sat, Apr 11, 2009 at 12:21:57AM +, Perry E. Metzger wrote:
> 
> > Modified Files:
> > src/sys/fs/tmpfs: tmpfs_vnops.c
> > 
> > Log Message:
> > SAVENAME was not set for rename and delete as required
> > 
> > Patch from christos, fixes pr 41183
> 
> Now it leaks pathname buffers.
> 
> Who reviewed this change and who okayed it?

Hmm, does this work correctly if you find the component via the
cache_lookup() path?


Re: CVS commit: src/usr.bin/ftp

2009-04-24 Thread Luke Mewburn
On Fri, Apr 24, 2009 at 02:07:56PM +1000, Geoff Wing wrote:
  | On Sunday 2009-04-12 10:18 +, Luke Mewburn output:
  | :Module Name:   src
  | :Committed By:  lukem
  | :Date:  Sun Apr 12 10:18:52 UTC 2009
  | :
  | :Modified Files:
  | :   src/usr.bin/ftp: cmds.c cmdtab.c complete.c domacro.c extern.h fetch.c
  | :   ftp.c ftp_var.h main.c progressbar.c progressbar.h util.c version.h
  | :
  | :Log Message:
  | :Fix numerous WARNS=4 issues (-Wcast-qual -Wsign-compare).
  | :cvs rdiff -u -r1.114 -r1.115 src/usr.bin/ftp/main.c
  | 
  | 
  | @@ -570,7 +574,7 @@
  | anonftp = 0;
  | autologin = 0;
  | }
  | -   setpeer(argc+1, xargv);
  | +   setpeer(3, xargv);
  | autologin = oautologin;
  | if (connected == 1 && uuser != NULL)
  | (void)ftp_login(host, uuser, NULL);
  | 
  | 
  | This is a functional change, not a WARNS=4 issue.  And it's wrong.
  | 
  | Try "ftp ", e.g.
  | % ftp ftp.netbsd.org.

Fixed.

thanks,
Luke.


pgp9OHLko5jmP.pgp
Description: PGP signature