_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-...@freebsd.org"
Linux says the same. But it's irrelevant what they say.
FreeBSD is not Plan 9, and FreeBSD is not Linux.
Procfs has a long history of security vulnerabilities and
other problems. I do not mount procfs on most machines
I'm responsible for, especially not on machines that have
user accounts or services that are not restricted to jails.
I also think it is inefficient to let the kernel render
data to ASCII, and then have userland tools parse that
ASCII data again. That's ridiculous. There is no sane
reason for putting kernel data as ASCII text into a pseudo
file system.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"anyone new to programming should be kept as far from C++ as
possible; actually showing the stuff should be considered a
criminal offence" -- Jacek Generowicz
I don't want to start a debate, but I disagree on the last point. If
anything, the filesystem concept for data acquisition (from the kernel)
most definitely falls under the "true UNIX way". I disagree with this
data being made available under /proc, but I do feel what's provided as
a simple file-based interface is the Right Thing(tm). Here's why:
Programmers are strictly limited to the sysctl(3) interface, or get to
do horrible things like fork()/exec() sysctl(8) repetitively for data.
How efficient! Aside from C, I'm not aware of any programming languages
that have native tie-ins to sysctl(3). I am explicitly excluding
third-party modules for perl and other whatnots; they're silly. With a
filesystem that provides sysctl data, you can literally use anything you
want to get information: /bin/sh, python, perl, PHP, Tcl/Tk, Ruby, Java,
or anything else.
As it stands today, the programming language is effectively made
retarded by repetitive calls to sysctl(8) to get data, check exit codes,
not to mention the repetitive fork()/exec() requirements.
For years now I have been considering a sysctl filesystem (e.g. mounted
as /sysctl) which would solve this dilemma. Read-only might be a wise
choice for this too. But this is beyond my skill set at this time, and
the existing documentation/examples for a pseudo filesystem are really
not that great.
By the way, did you know present-day FreeBSD "ps -e" doesn't work? Try
it and notice what the first line of output is. There are some other
base system utilities that behave the same way (thing-X doesn't work
without procps, and god forbid you use/mount it). I agree that procps
should be removed, but the way this came about was obviously done in
haste. Not cool.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
1. How to request the data in question from the kernel: by reading a file, or by making a dedicated system call. Jeremy says read a file.
2. The format the kernel returns the data in. Oliver says the Plan 9 way of the kernel rendering text and then userland tools parsing text is silly. The kernel should return binary, which userland tools can then use directly, or render to text for a person to read.
3. Conflating /proc with Jeremy's /sysctl.
4. Whether /proc and/or /sysctl should be read-only.
5. Whether things in different security domains should see the same procfs.
The question I meant to ask was just the first one. What's wrong with requesting the data by reading a file instead of making a dedicated system call? What's the advantage of the system call?
But since the other issues came up: 2, I agree the kernel should return binary. 3, separate /proc and /sysctl. 4, no comment. 5, Oliver, didn't you answer your own objection? If things are supposed to be in the same security domain, then there can't be a vulnerability caused by them sharing a common procfs, and if they're supposed to be in different security domains, then put them in jails, where they don't share a common procfs.
Jeremy, when you said procfs should be removed, did you mean just for the same reasons Oliver said, or did you have other reasons?
The security issues are long-standing and there have been many over the
years, but the real reason is something that's less evident (or at least
less directly apparent):
Simply put, procfs on FreeBSD has been neglected. There isn't a lot of
attention being given to it, and the only modifications in recent
months/years have been generally minor compared to the rest of the tree.
You can review some of the commits yourself:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/procfs/
Others like yourself have asked what the state of procfs is, going back
as far as 2005. Be sure to read the reply as well:
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2005-05/2607.html
There was also a commit comment circa 2008 to the RELENG_7 branch that
indicates procfs is "now-deprecated":
http://freshbsd.org/2008/04/10/20/54/02
...yet there have been commits as recent as 2009 to fix important
utilities -- gcore(1) and gdb(1) -- to work without procps, which adds
further evidence that procfs may have been hastily forgotten/dropped
without a full review of what relied upon it:
http://freshbsd.org/2009/12/19/19/30/27
Alternate solutions or changes to procfs have been mentioned over the
years, such as in 2008 by a user on freebsd-arch, who received no reply:
http://lists.freebsd.org/pipermail/freebsd-arch/2008-March/007750.html
Finally, there is an official maintainer of procfs (see procfs.c at the
first link, then look for the Sep 23 2009 commit). You may want to
privately ask that individual what the current state of affairs is.
The /sysctl filesystem idea I've had I still feel is the best solution,
but *should not* be based on the procfs code (they're two different
beasts, despite having similar functionality). It should be written
from scratch.
I was quite serious when I said I wish I could write such a thing,
because the benefits of such are huge, especially when it comes to *any*
form of counter/statistic-gathering or monitoring capability on FreeBSD.
Honestly, it's a project that seems perfect for GSoC.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
_______________________________________________
Actually, the replacement for procfs is not sysctl, but ptrace(2), and there
has been a long-running process in place to migrate tools such as truss, etc.
from using procfs to use ptrace(2) instead and to add new features to
ptrace(2) when there were things it did not support that procfs did. One
could argue that some of the more recent things like the sysctl's for procstat
-v or procstat -k should have been implemented as new ptrace OPs rather than
sysctls (and I'd probably agree with you).
--
John Baldwin
I have been following this discussion with my jaw agape. It seems
that the many men standing around this elephant are all perceiving
completely different things based on their own interests and
experiences.
My own software is using procfs to efficiently determine the path to
the currently running executable. I am sure that other software does
the same since Linux procfs (and probably OS X) supports the same
mechanism. It is difficult to imagine how this would be done via
ptrace(2).
Bob
--
Bob Friesenhahn
bfri...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Or, you use sysctl kern.proc.vmmap and get essentially the same data.
PT_VM_ENTRY was added long after the sysctl, I did not objected exactly
because ptrace(2) looked more logical.
The advantage of using procfs or sysctl instead of ptrace(2) is that
you do not need to attach as debugger, causing the issues with signal
delivery for the debugee.
http://www.mail-archive.com/freebsd...@freebsd.org/msg38829.html
:)
--
Pawel Jakub Dawidek http://www.wheelsystems.com
p...@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
Yummy :)
Find below the make output on 8.2-PRERELEASE 21/02/2011
I suppose a lot of stuff changed since 2002 and an update would be required.
--
mybsd root /tmp/sysctlfs/sysctlfs
# make
"/usr/share/mk/bsd.compat.mk", line 35: warning: NOMAN is deprecated in
favour of NO_MAN
Warning: Object directory not changed from original /tmp/sysctlfs/sysctlfs
@ -> /usr/src/sys
machine -> /usr/src/sys/amd64/include
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-common
-fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387
-mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -c sysctlfs_subr.c
In file included from sysctlfs_subr.c:16:
vnode.h:46:26: error: machine/lock.h: No such file or directory
In file included from sysctlfs_subr.c:16:
vnode.h:118: error: field 'v_interlock' has incomplete type
vnode.h:127: error: field 'vpi_lock' has incomplete type
vnode.h:128: error: field 'vpi_selinfo' has incomplete type
vnode.h:183: error: expected specifier-qualifier-list before 'udev_t'
In file included from vnode_if.h:10,
from vnode.h:532,
from sysctlfs_subr.c:16:
vnode_if_newproto.h:11: error: expected specifier-qualifier-list before
'vop_bypass_t'
cc1: warnings being treated as errors
In file included from vnode.h:532,
from sysctlfs_subr.c:16:
vnode_if.h: In function 'VOP_ISLOCKED':
vnode_if.h:28: warning: passing argument 1 of 'VOP_ISLOCKED_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_LOOKUP':
vnode_if.h:54: warning: passing argument 1 of 'VOP_LOOKUP_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_CACHEDLOOKUP':
vnode_if.h:80: warning: passing argument 1 of 'VOP_CACHEDLOOKUP_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_CREATE':
vnode_if.h:109: warning: passing argument 1 of 'VOP_CREATE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_WHITEOUT':
vnode_if.h:135: warning: passing argument 1 of 'VOP_WHITEOUT_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_MKNOD':
vnode_if.h:164: warning: passing argument 1 of 'VOP_MKNOD_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_OPEN':
vnode_if.h:196: warning: passing argument 1 of 'VOP_OPEN_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_CLOSE':
vnode_if.h:225: warning: passing argument 1 of 'VOP_CLOSE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_ACCESS':
vnode_if.h:254: warning: passing argument 1 of 'VOP_ACCESS_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_ACCESSX':
vnode_if.h:283: warning: passing argument 1 of 'VOP_ACCESSX_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_GETATTR':
vnode_if.h:309: warning: passing argument 1 of 'VOP_GETATTR_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_SETATTR':
vnode_if.h:335: warning: passing argument 1 of 'VOP_SETATTR_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_MARKATIME':
vnode_if.h:355: warning: passing argument 1 of 'VOP_MARKATIME_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_READ':
vnode_if.h:384: warning: passing argument 1 of 'VOP_READ_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_WRITE':
vnode_if.h:413: warning: passing argument 1 of 'VOP_WRITE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_IOCTL':
vnode_if.h:448: warning: passing argument 1 of 'VOP_IOCTL_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_POLL':
vnode_if.h:477: warning: passing argument 1 of 'VOP_POLL_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_KQFILTER':
vnode_if.h:500: warning: passing argument 1 of 'VOP_KQFILTER_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_REVOKE':
vnode_if.h:523: warning: passing argument 1 of 'VOP_REVOKE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_FSYNC':
vnode_if.h:549: warning: passing argument 1 of 'VOP_FSYNC_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_REMOVE':
vnode_if.h:575: warning: passing argument 1 of 'VOP_REMOVE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_LINK':
vnode_if.h:601: warning: passing argument 1 of 'VOP_LINK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_RENAME':
vnode_if.h:636: warning: passing argument 1 of 'VOP_RENAME_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_MKDIR':
vnode_if.h:665: warning: passing argument 1 of 'VOP_MKDIR_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_RMDIR':
vnode_if.h:691: warning: passing argument 1 of 'VOP_RMDIR_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_SYMLINK':
vnode_if.h:723: warning: passing argument 1 of 'VOP_SYMLINK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_READDIR':
vnode_if.h:758: warning: passing argument 1 of 'VOP_READDIR_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_READLINK':
vnode_if.h:784: warning: passing argument 1 of 'VOP_READLINK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_INACTIVE':
vnode_if.h:807: warning: passing argument 1 of 'VOP_INACTIVE_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_RECLAIM':
vnode_if.h:830: warning: passing argument 1 of 'VOP_RECLAIM_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_LOCK1':
vnode_if.h:859: warning: passing argument 1 of 'VOP_LOCK1_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_UNLOCK':
vnode_if.h:882: warning: passing argument 1 of 'VOP_UNLOCK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_BMAP':
vnode_if.h:917: warning: passing argument 1 of 'VOP_BMAP_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_STRATEGY':
vnode_if.h:940: warning: passing argument 1 of 'VOP_STRATEGY_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_GETWRITEMOUNT':
vnode_if.h:963: warning: passing argument 1 of 'VOP_GETWRITEMOUNT_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_PRINT':
vnode_if.h:983: warning: passing argument 1 of 'VOP_PRINT_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_PATHCONF':
vnode_if.h:1009: warning: passing argument 1 of 'VOP_PATHCONF_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_ADVLOCK':
vnode_if.h:1041: warning: passing argument 1 of 'VOP_ADVLOCK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_ADVLOCKASYNC':
vnode_if.h:1079: warning: passing argument 1 of 'VOP_ADVLOCKASYNC_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_REALLOCBLKS':
vnode_if.h:1102: warning: passing argument 1 of 'VOP_REALLOCBLKS_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_GETPAGES':
vnode_if.h:1134: warning: passing argument 1 of 'VOP_GETPAGES_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_PUTPAGES':
vnode_if.h:1169: warning: passing argument 1 of 'VOP_PUTPAGES_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_GETACL':
vnode_if.h:1201: warning: passing argument 1 of 'VOP_GETACL_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_SETACL':
vnode_if.h:1233: warning: passing argument 1 of 'VOP_SETACL_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_ACLCHECK':
vnode_if.h:1265: warning: passing argument 1 of 'VOP_ACLCHECK_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_CLOSEEXTATTR':
vnode_if.h:1294: warning: passing argument 1 of 'VOP_CLOSEEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_GETEXTATTR':
vnode_if.h:1332: warning: passing argument 1 of 'VOP_GETEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_LISTEXTATTR':
vnode_if.h:1367: warning: passing argument 1 of 'VOP_LISTEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_OPENEXTATTR':
vnode_if.h:1393: warning: passing argument 1 of 'VOP_OPENEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_DELETEEXTATTR':
vnode_if.h:1425: warning: passing argument 1 of 'VOP_DELETEEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_SETEXTATTR':
vnode_if.h:1460: warning: passing argument 1 of 'VOP_SETEXTATTR_APV'
from incompatible pointer type
vnode_if.h: In function 'VOP_SETLABEL':
vnode_if.h:1489: warning: passing argument 1 of 'VOP_SETLABEL_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_VPTOFH':
vnode_if.h:1512: warning: passing argument 1 of 'VOP_VPTOFH_APV' from
incompatible pointer type
vnode_if.h: In function 'VOP_VPTOCNP':
vnode_if.h:1544: warning: passing argument 1 of 'VOP_VPTOCNP_APV' from
incompatible pointer type
In file included from sysctlfs_subr.c:16:
vnode.h: At top level:
vnode.h:551: warning: 'struct vop_lease_args' declared inside parameter list
vnode.h:551: warning: its scope is only this definition or declaration,
which is probably not what you want
vnode.h:554: error: expected declaration specifiers or '...' before 'udev_t'
vnode.h:568: warning: 'struct vop_lease_args' declared inside parameter list
vnode.h:619: warning: 'struct vop_lock_args' declared inside parameter list
vnode.h:622: warning: 'struct vop_lock_args' declared inside parameter list
vnode.h:628: warning: 'struct vop_lock_args' declared inside parameter list
vnode.h:636: warning: 'struct vop_createvobject_args' declared inside
parameter list
vnode.h:637: warning: 'struct vop_destroyvobject_args' declared inside
parameter list
vnode.h:638: warning: 'struct vop_getvobject_args' declared inside
parameter list
sysctlfs_subr.c: In function 'sysctlfs_allocvp':
sysctlfs_subr.c:152: error: 'securelevel' undeclared (first use in this
function)
sysctlfs_subr.c:152: error: (Each undeclared identifier is reported only
once
sysctlfs_subr.c:152: error: for each function it appears in.)
sysctlfs_subr.c:154: error: 'struct proc' has no member named 'p_prison'
sysctlfs_subr.c: In function 'sysctlfs_rw':
sysctlfs_subr.c:251: error: 'struct uio' has no member named 'uio_procp'
sysctlfs_subr.c: In function 'sysctlfs_sysctl':
sysctlfs_subr.c:353: error: 'struct sysctl_req' has no member named 'p'
sysctlfs_subr.c:376: error: 'securelevel' undeclared (first use in this
function)
sysctlfs_subr.c:382: error: 'struct sysctl_req' has no member named 'p'
sysctlfs_subr.c:383: warning: implicit declaration of function 'suser_xxx'
sysctlfs_subr.c:383: warning: nested extern declaration of 'suser_xxx'
sysctlfs_subr.c:383: error: 'struct sysctl_req' has no member named 'p'
sysctlfs_subr.c:384: error: 'PRISON_ROOT' undeclared (first use in this
function)
*** Error code 1
Stop in /tmp/sysctlfs/sysctlfs.
---
It would not be the first syscall to return a path to userland (see
__getcwd()). Presumably the reason a ptrace(2) OP has not been added
for that is that it is that nothing that was ported from procfs to
ptrace(2) has needed it.
--
John Baldwin
Another advantage I find of (linux) procfs is that you always get a textual
version of it, which can be useful in shell scripts and debugging situations.
/sbin/sysctl kern.proc.vmmap isn't usable because the command has no way to
specify the pid.
/usr/bin/procstat gives access to only part of the procfs and sysctl
namespace.
__Martin
http://netbsd.gw.com/cgi-bin/man-cgi?mount_sysctlfs++NetBSD-current
At fusion-io we have abstracted the control stuff
to export as sysctl when compiled in the freebsd driver and procfs in
the linux driver.
While sysctl is 'ok' I will admit that the procfs variant is a bit
more convenient to use.
simply because you can enumerate the damned tree without seeing all
the contents.
> There is no sane
> reason for putting kernel data as ASCII text into a pseudo
> file system.
>
> Best regards
> Oliver
This is fantastic, except for the fact that it's abstracted by something
called puffs. I took a look at the NetBSD source code for this
(src/usr.sbin/puffs/mount_sysctlfs, tag netbsd-5) and puffs is
absolutely required for it to work.
http://netbsd.gw.com/cgi-bin/man-cgi?puffs+4+NetBSD-current
http://netbsd.gw.com/cgi-bin/man-cgi?puffs+3+NetBSD-current
Simply put, someone would have to port puffs for mount_sysctlfs to work
on FreeBSD. There is already efforts underway to do that, but I have
absolutely no idea what the status of it is:
http://wiki.freebsd.org/SOC2009TatsianaSeveryna
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
_______________________________________________
If by contents you mean values then try the sysctl -N option (though that
still does a recursive enumeration).
__Martin