71a8cbcb20
HEAD to RELENG_6: changes to introduce a credentialed version of the
clone event handler, and then changes to merge the regular and
credentialed versions into a single interface (along with updates to
existing consumers). With this merge, 6.x and 7.x are in sync.
First batch merges devfs_devs.c:1.37, devfs_vnops.c:1.115,
kern_conf.c:1.187, tty_pty.c:1.138, mac_vfs.c:1.109, mac_biba.c:1.36,
mac_lomac.c:1.36, mac_mls.c:1.73, mac_stub.c:1.53, mac_test.c:1.61,
conf.h:1.223, mac.h:1.68, mac_policy.h:1.67 from HEAD to RELENG_6:
When devfs cloning takes place, provide access to the credential of the
process that caused the clone event to take place for the device driver
creating the device. This allows cloned device drivers to adapt the
device node based on security aspects of the process, such as the uid,
gid, and MAC label.
- Add a cred reference to struct cdev, so that when a device node is
instantiated as a vnode, the cloning credential can be exposed to
MAC.
- Add make_dev_cred(), a version of make_dev() that additionally
accepts the credential to stick in the struct cdev. Implement it and
make_dev() in terms of a back-end make_dev_credv().
- Add a new event handler, dev_clone_cred, which can be registered to
receive the credential instead of dev_clone, if desired.
- Modify the MAC entry point mac_create_devfs_device() to accept an
optional credential pointer (may be NULL), so that MAC policies can
inspect and act on the label or other elements of the credential
when initializing the skeleton device protections.
- Modify tty_pty.c to register clone_dev_cred and invoke make_dev_cred(),
so that the pty clone credential is exposed to the MAC Framework.
While currently primarily focussed on MAC policies, this change is also
a prerequisite for changes to allow ptys to be instantiated with the UID
of the process looking up the pty. This requires further changes to the
pty driver -- in particular, to immediately recycle pty nodes on last
close so that the credential-related state can be recreated on next
lookup.
Submitted by: Andrew Reisse <andrew.reisse@sparta.com>
Obtained from: TrustedBSD Project
Sponsored by: SPAWAR, SPARTA
Second batch merges scsi_target.c:1.68, coda_fbsd.c:1.43,
firewirereg.h:1.38, fwdev.c:1.47, nmdm.c:1.36, snp.c:1.100, dsp.c:1.82,
mixer.c:1.45, vkbd.c:1.9, devfs_vnops.c:1.117, tty_pty.c:1.139,
tty_tty.c:1.57, bpf.c:1.156, if_tap.c:1.56, if_tun.c:1.153,
smb_dev.c:1.28, conf.h:1.224 from HEAD to RELENG_6:
Merge the dev_clone and dev_clone_cred event handlers into a single
event handler, dev_clone, which accepts a credential argument.
Implementors of the event can ignore it if they're not interested,
and most do. This avoids having multiple event handler types and
fall-back/precedence logic in devfs.
This changes the kernel API for /dev cloning, and may affect third
party packages containg cloning kernel modules.
Requested by: phk
These changes modifies the kernel device driver API for device cloning,
and might require minor modifications to third party device drivers that
make use of devfs cloning. It will not be merged to RELENG_5.
Approved by: re (scottl)
|
||
|---|---|---|
| .. | ||
| 00READ | ||
| cnode.h | ||
| coda_fbsd.c | ||
| coda_io.h | ||
| coda_kernel.h | ||
| coda_namecache.c | ||
| coda_namecache.h | ||
| coda_opstats.h | ||
| coda_pioctl.h | ||
| coda_psdev.c | ||
| coda_psdev.h | ||
| coda_subr.c | ||
| coda_subr.h | ||
| coda_venus.c | ||
| coda_venus.h | ||
| coda_vfsops.c | ||
| coda_vfsops.h | ||
| coda_vnops.c | ||
| coda_vnops.h | ||
| coda.h | ||
| README | ||
| TODO | ||
$FreeBSD$
Announcing the Availability of the
Coda Distributed
Filesystem
for
BSD Unix Systems
Coda is a distributed filesystem like NFS and AFS. It is
freely available, like NFS. But it functions much like AFS in being a
"stateful" filesystem. Coda and AFS cache files on your local
machine to improve performance. But Coda goes a step further than AFS
by letting you access the cached files when there is no available
network, viz. disconnected laptops and network outages. In Coda, both
the client and server are outside the kernel which makes them easier
to experiment with.
To get more information on Coda, I would like to refer people to
http://www.coda.cs.cmu.edu
There is a wealth of documents, papers, and theses there. There is
also a good introduction to the Coda File System in
http://www.coda.cs.cmu.edu/ljpaper/lj.html
Coda was originally developed as an academic prototype/testbed. It is
being polished and rewritten where necessary. Coda is a work in
progress and does have bugs. It is, though, very usable. Our
interest is in making Coda available to as many people as possible and
to have Coda evolve and flourish.
The bulk of the Coda filesystem code supports the Coda client
program, the Coda server program and the utilities needed by both.
All these programs are unix programs and can run equally well on any
Unix platform. Our main development thrust is improving these
programs. There is a small part of Coda that deals with the kernel to
filesystem interface. This code is OS specific (but should not be
platform specific).
Coda is currently available for several OS's and platforms:
Freebsd-2.2.5: i386
Freebsd-2.2.6: i386
Freebsd -current: i386
linux 2.0: i386 & sparc
linux 2.1: i386 & sparc
NetBSD 1.3: i386
NetBSD -current: i386
The relevant sources, binaries, and docs can be found in
ftp://ftp.coda.cs.cmu.edu/pub/coda/
We intend to come out with new Coda releases often, not daily. We
don't want to slight any OS/platform not mentioned above. We are just
limited in our resources as to what we can support internally. We
will be happy to integrate OpenBSD support as well as other OS
support. Also, adding platform support should be relatively easy and
we can discuss this. The only difficulty is that Coda has a light weight
process package. It does some manipulations in assembler which would
have to be redone for a different platform.
There are several mailing lists @coda.cs.cmu.edu that discuss coda:
coda-announce and linux-coda. We are going to revise linux-coda to be
OS neutral, since it is mainly Coda we want to discuss. We appreciate
comments, feedback, bug reports, bug fixes, enhancements, etc.