Christos Zoulas --> current-users (2005-04-13 00:50:45 -0400):
> In article <20050412232716.GA3221@moray.salmi.ch>,
> Jukka Salmi  <j+nbsd@2005.salmi.ch> wrote:
> >Jukka Salmi --> current-users (2005-04-12 22:36:07 +0200):
> >> on a current i386 system, cap_mkdb creates an empty db if no output
> >> filename (-f option) is specified (or if it's equal to the first input
> >> filename):
> >> 
> >> 
> >> $ cp /usr/share/misc/termcap .
> >> $ cap_mkdb -v termcap
> >> cap_mkdb: 0 capability records
> >> $ rm termcap.db
> >> $ cap_mkdb -v -f out termcap
> >> [...]
> >> cap_mkdb: 1032 capability records
> >> 
> >> The same commands on a netbsd-2 system:
> >> 
> >> $ cp /usr/share/misc/termcap .
> >> $ cap_mkdb -v termcap
> >> [...]
> >> cap_mkdb: 1032 capability records
> >> $ rm termcap.db
> >> $ cap_mkdb -v -f out termcap 
> >> [...]
> >> cap_mkdb: 1032 capability records
> >> 
> >> 
> >> Is this a bug, or am I missing something?
> >
> >Hmm, using a netbsd-2 libc seems to make it work:
> >
> >$ LD_LIBRARY_PATH=/opt/nbsd/2/lib cap_mkdb -v termcap
> >[...]
> >cap_mkdb: 1032 capability records
> >
> >
> >Any hints?
> 
> I just fixed this.

Indeed, that problem is fixed.

Maybe I just didn't notice a similar problem then or this is a new
regression, but AFAICT cap_mkdb(1) still isn't working...

At first glance everything looks fine:

$ ls -l /etc/login.conf
-rw-r--r--  1 root  wheel     77 May  7 02:26 /etc/login.conf
-rw-r--r--  1 root  wheel  16384 May  7 02:26 /etc/login.conf.db

$ vi /etc/login.conf
[... change `maxproc' from 20 to 50 ...]
:wq

$ cat /etc/login.conf
restricted|restricted user:\
        :coredumpsize=0:maxproc=50:

$ sudo cap_mkdb -v /etc/login.conf
cap_mkdb: 1 capability records

$ ls -l /etc/login.conf
-rw-r--r--  1 root  wheel     77 May  7 02:27 /etc/login.conf
-rw-r--r--  1 root  wheel  16384 May  7 02:28 /etc/login.conf.db

But then I noticed that users in the `restricted' class were still
using old settings (after login...). Tracing cap_mkdb revealed:

[...]
  8123      1 cap_mkdb CALL  open(0xbfbfec78,0,0x1b6)
  8123      1 cap_mkdb NAMI  "/etc/login.conf"
  8123      1 cap_mkdb RET   open 3
[...]
  8123      1 cap_mkdb CALL  read(3,0x804e000,0x2000)
[...]
  8123      1 cap_mkdb CALL  close(3)
[...]
  8123      1 cap_mkdb CALL  open(0x804d040,0x602,0x1b6)
  8123      1 cap_mkdb NAMI  "/etc/login.conf.db.tmp"
  8123      1 cap_mkdb RET   open 3
[...]
  8123      1 cap_mkdb CALL  open(0xbfbfec78,0,0x1b6)
  8123      1 cap_mkdb NAMI  "/etc/login.conf"
  8123      1 cap_mkdb RET   open 4
[...]
  8123      1 cap_mkdb CALL  read(4,0x8052000,0x2000)
[...]
  8123      1 cap_mkdb CALL  open(0xbfbfde30,0,0)
  8123      1 cap_mkdb NAMI  "/etc/login.conf.db"
  8123      1 cap_mkdb RET   open 5
[...]
  8123      1 cap_mkdb CALL  read(5,0x804e200,0x104)
[...]
[... reading old settings! ...]
[...]
  8123      1 cap_mkdb CALL  close(5)
[...]
  8123      1 cap_mkdb CALL  close(4)
[...]
  8123      1 cap_mkdb CALL  pwrite(3,0x8055000,0x1000,0,0x2000,0)
[...]
[... writing old settings! ...]
[...]
  8123      1 cap_mkdb GIO   fd 3 wrote 8 bytes
[...]
  8123      1 cap_mkdb RET   pwrite 4096/0x1000
  8123      1 cap_mkdb CALL  close(3)
  8123      1 cap_mkdb RET   close 0
  8123      1 cap_mkdb CALL  rename(0x804d040,0x804a700)
  8123      1 cap_mkdb NAMI  "/etc/login.conf.db.tmp"
  8123      1 cap_mkdb NAMI  "/etc/login.conf.db"
  8123      1 cap_mkdb RET   rename 0
  8123      1 cap_mkdb CALL  exit(0)


Of course unlinking /etc/login.conf.db before running cap_mkdb fixes
the problem. But cap_mkdb should overwrite the .db file, shouldn't it?

TIA, Jukka

-- 
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~