From owner-freebsd-hackers  Fri Nov 10 07:44:40 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id HAA28966
          for hackers-outgoing; Fri, 10 Nov 1995 07:44:40 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA28959
          for <hackers@FreeBSD.org>; Fri, 10 Nov 1995 07:44:34 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA11179; Sat, 11 Nov 1995 02:38:36 +1100
Date: Sat, 11 Nov 1995 02:38:36 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511101538.CAA11179@godzilla.zeta.org.au>
To: fn@pain.csrv.uidaho.edu, hackers@FreeBSD.org
Subject: Re: vnconfig question.
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

>-rw-rw-r--  1 root  wheel  16777216 Nov  8 23:06 swapfile


>ie, read perms for everyone on the swapfile.

>this is (obviously) bad for security.  i guess if i'd thought a

>does it make sense to change vnconfig to automatically adjust the
>permissions of a vnode file upon configuring, or to warn the user?
>if so, should it do that upon configuring for any file, or for just
>swapfiles (i'm guessing swapfiles only)?

The largest hole is for a user-writeable file system image that
gets mounted.  There's nothing vnconfig can do about that except
to refuse to config it.

>i hacked together a patch which would change the permissions on the
>swapfile if vnconfig -e ... ... swap is used.  it's a bad patch because
>(i think!) people can do

>	vnconfig -c /dev/vn0b /blah/swapfile
>	swapon /dev/vn0b

>and it does nothing to the swapfile in that case.

Perhaps the file permissions should be at least as restrictive as the most
restrictive vn device permission.

Bruce