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