Regarding FreeBSD

Robert Watson rwatson at freebsd.org
Tue Jul 20 19:50:07 PDT 2004


On Mon, 19 Jul 2004, ravi wrote:

> Hi,
> 1) Can u explain me the usage of different arguments to 	pf_create_file
> () function ?

Again, details a bit hazy to me here, but roughly speaking: 

  'parent' is the parent directory where the object will appear

  'name' is the name it will have

  'fill' is the function pointer provided by the pseudofs-derived file
  system to implement the node.  I.e., procfs_doproccmdline.

  'attr' appears to be a function pointer allowing the pseudo file system
  to modify the set of attributes returned for a node; this is used by
  procfs to modify the set of permissions returns for certain objects
  (looks like the debugging entries in per-process directories).

  'vis' is a visibility test function: should the node be visible to a
  particular caller (i.e., "you can't see that process for security
  reasons").

  'flags' is a set of node flags, such as PFS_RD, PFS_WR, etc, as found in
  pseudofs.h.

I'd suggest working from examples in src/sys/fs/procfs/procfs.c; pseudofs
is largely an abstraction layer to let the bulk of the file system logic
be shared between procfs and linprocfs, since they're similar (but
different).

> 2) what is the use of PFS_PROCDEP in the following statement ?
> 
>  dir = pfs_create_dir(root, "pid",
>             procfs_attr, NULL, PFS_PROCDEP);

As I mentioned in a previous e-mail, it's creating a template per-process
directory that will be expanded into many perceived directories on demand,
one per process.  If you look at procfs_init(), you'll see that it creates
the template, then places a bunch of nodes in the template that will be
valid for each process.

> 3) there is no entry under /proc with the name "pid" .  Why is it so ? 

See previous e-mail -- the template has its name replaced with each
possible pid, and 'pid' is a place-holder.

> 4) And even though for some of the proc entries the permission given is
> PFS_RDWR , the file is getting created with the read permission only . 
> 
> What is the reason for this ? 

pfs_getattr() appears to always return read-only entries, except where
pn_attr() is implemented on the node.  The actual protections appear to be
calculated in several places -- for example, pfs_visible() uses various
visibility tests, including per-process tests, etc.  The permission bits
are probably not a perfect guide to access rights.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Principal Research Scientist, McAfee Research



More information about the freebsd-fs mailing list