diff options
Diffstat (limited to 'share')
23 files changed, 0 insertions, 3905 deletions
diff --git a/share/colldef/la_LN.US-ASCII.src b/share/colldef/la_LN.US-ASCII.src deleted file mode 100644 index df3c34088764..000000000000 --- a/share/colldef/la_LN.US-ASCII.src +++ /dev/null @@ -1,6 +0,0 @@ -# ASCII -# -# $FreeBSD$ -# -order \ - \x00;...;\xff diff --git a/share/colldef/map.ISO8859-1 b/share/colldef/map.ISO8859-1 deleted file mode 100644 index ee5a557ca627..000000000000 --- a/share/colldef/map.ISO8859-1 +++ /dev/null @@ -1,174 +0,0 @@ -NU \x00 -SH \x01 -SX \x02 -EX \x03 -ET \x04 -EQ \x05 -AK \x06 -BL \x07 -BS \x08 -HT \x09 -LF \x0a -VT \x0b -FF \x0c -CR \x0d -SO \x0e -SI \x0f -DL \x10 -D1 \x11 -D2 \x12 -D3 \x13 -D4 \x14 -NK \x15 -SY \x16 -EB \x17 -CN \x18 -EM \x19 -SB \x1a -EC \x1b -FS \x1c -GS \x1d -RS \x1e -US \x1f -SP \x20 -Nb \x23 -DO \x24 -At \x40 -<( \x5b -// \x5c -)> \x5d -'> \x5e -'! \x60 -(! \x7b -!! \x7c -!) \x7d -'? \x7e -DT \x7f -PA \x80 -HO \x81 -BH \x82 -NH \x83 -IN \x84 -NL \x85 -SA \x86 -ES \x87 -HS \x88 -HJ \x89 -VS \x8a -PD \x8b -PU \x8c -RI \x8d -S2 \x8e -S3 \x8f -DC \x90 -P1 \x91 -P2 \x92 -TS \x93 -CC \x94 -MW \x95 -SG \x96 -EG \x97 -SS \x98 -GC \x99 -SC \x9a -CI \x9b -ST \x9c -OC \x9d -PM \x9e -AC \x9f -NS \xa0 -!I \xa1 -Ct \xa2 -Pd \xa3 -Cu \xa4 -Ye \xa5 -BB \xa6 -SE \xa7 -': \xa8 -Co \xa9 --a \xaa -<< \xab -NO \xac --- \xad -Rg \xae -'m \xaf -DG \xb0 -+- \xb1 -2S \xb2 -3S \xb3 -'' \xb4 -My \xb5 -PI \xb6 -.M \xb7 -', \xb8 -1S \xb9 --o \xba ->> \xbb -14 \xbc -12 \xbd -34 \xbe -?I \xbf -A! \xc0 -A' \xc1 -A> \xc2 -A? \xc3 -A: \xc4 -AA \xc5 -AE \xc6 -C, \xc7 -E! \xc8 -E' \xc9 -E> \xca -E: \xcb -I! \xcc -I' \xcd -I> \xce -I: \xcf -D- \xd0 -N? \xd1 -O! \xd2 -O' \xd3 -O> \xd4 -O? \xd5 -O: \xd6 -*X \xd7 -O/ \xd8 -U! \xd9 -U' \xda -U> \xdb -U: \xdc -Y' \xdd -TH \xde -ss \xdf -a! \xe0 -a' \xe1 -a> \xe2 -a? \xe3 -a: \xe4 -aa \xe5 -ae \xe6 -c, \xe7 -e! \xe8 -e' \xe9 -e> \xea -e: \xeb -i! \xec -i' \xed -i> \xee -i: \xef -d- \xf0 -n? \xf1 -o! \xf2 -o' \xf3 -o> \xf4 -o? \xf5 -o: \xf6 --: \xf7 -o/ \xf8 -u! \xf9 -u' \xfa -u> \xfb -u: \xfc -y' \xfd -th \xfe -y: \xff diff --git a/share/colldef/map.ISO8859-15 b/share/colldef/map.ISO8859-15 deleted file mode 100644 index 041dd5a1311b..000000000000 --- a/share/colldef/map.ISO8859-15 +++ /dev/null @@ -1,174 +0,0 @@ -NU \x00 -SH \x01 -SX \x02 -EX \x03 -ET \x04 -EQ \x05 -AK \x06 -BL \x07 -BS \x08 -HT \x09 -LF \x0a -VT \x0b -FF \x0c -CR \x0d -SO \x0e -SI \x0f -DL \x10 -D1 \x11 -D2 \x12 -D3 \x13 -D4 \x14 -NK \x15 -SY \x16 -EB \x17 -CN \x18 -EM \x19 -SB \x1a -EC \x1b -FS \x1c -GS \x1d -RS \x1e -US \x1f -SP \x20 -Nb \x23 -DO \x24 -At \x40 -<( \x5b -// \x5c -)> \x5d -'> \x5e -'! \x60 -(! \x7b -!! \x7c -!) \x7d -'? \x7e -DT \x7f -PA \x80 -HO \x81 -BH \x82 -NH \x83 -IN \x84 -NL \x85 -SA \x86 -ES \x87 -HS \x88 -HJ \x89 -VS \x8a -PD \x8b -PU \x8c -RI \x8d -S2 \x8e -S3 \x8f -DC \x90 -P1 \x91 -P2 \x92 -TS \x93 -CC \x94 -MW \x95 -SG \x96 -EG \x97 -SS \x98 -GC \x99 -SC \x9a -CI \x9b -ST \x9c -OC \x9d -PM \x9e -AC \x9f -NS \xa0 -!I \xa1 -Ct \xa2 -Pd \xa3 -Eu \xa4 -Ye \xa5 -S< \xa6 -SE \xa7 -s< \xa8 -Co \xa9 --a \xaa -<< \xab -NO \xac --- \xad -Rg \xae -'m \xaf -DG \xb0 -+- \xb1 -2S \xb2 -3S \xb3 -Z< \xb4 -My \xb5 -PI \xb6 -.M \xb7 -z< \xb8 -1S \xb9 --o \xba ->> \xbb -OE \xbc -oe \xbd -Y: \xbe -?I \xbf -A! \xc0 -A' \xc1 -A> \xc2 -A? \xc3 -A: \xc4 -AA \xc5 -AE \xc6 -C, \xc7 -E! \xc8 -E' \xc9 -E> \xca -E: \xcb -I! \xcc -I' \xcd -I> \xce -I: \xcf -D- \xd0 -N? \xd1 -O! \xd2 -O' \xd3 -O> \xd4 -O? \xd5 -O: \xd6 -*X \xd7 -O/ \xd8 -U! \xd9 -U' \xda -U> \xdb -U: \xdc -Y' \xdd -TH \xde -ss \xdf -a! \xe0 -a' \xe1 -a> \xe2 -a? \xe3 -a: \xe4 -aa \xe5 -ae \xe6 -c, \xe7 -e! \xe8 -e' \xe9 -e> \xea -e: \xeb -i! \xec -i' \xed -i> \xee -i: \xef -d- \xf0 -n? \xf1 -o! \xf2 -o' \xf3 -o> \xf4 -o? \xf5 -o: \xf6 --: \xf7 -o/ \xf8 -u! \xf9 -u' \xfa -u> \xfb -u: \xfc -y' \xfd -th \xfe -y: \xff diff --git a/share/colldef/map.ISO8859-2 b/share/colldef/map.ISO8859-2 deleted file mode 100644 index 75f201357172..000000000000 --- a/share/colldef/map.ISO8859-2 +++ /dev/null @@ -1,174 +0,0 @@ -NU \x00 -SH \x01 -SX \x02 -EX \x03 -ET \x04 -EQ \x05 -AK \x06 -BL \x07 -BS \x08 -HT \x09 -LF \x0a -VT \x0b -FF \x0c -CR \x0d -SO \x0e -SI \x0f -DL \x10 -D1 \x11 -D2 \x12 -D3 \x13 -D4 \x14 -NK \x15 -SY \x16 -EB \x17 -CN \x18 -EM \x19 -SB \x1a -EC \x1b -FS \x1c -GS \x1d -RS \x1e -US \x1f -SP \x20 -Nb \x23 -DO \x24 -At \x40 -<( \x5b -// \x5c -)> \x5d -'> \x5e -'! \x60 -(! \x7b -!! \x7c -!) \x7d -'? \x7e -DT \x7f -PA \x80 -HO \x81 -BH \x82 -NH \x83 -IN \x84 -NL \x85 -SA \x86 -ES \x87 -HS \x88 -HJ \x89 -VS \x8a -PD \x8b -PU \x8c -RI \x8d -S2 \x8e -S3 \x8f -DC \x90 -P1 \x91 -P2 \x92 -TS \x93 -CC \x94 -MW \x95 -SG \x96 -EG \x97 -SS \x98 -GC \x99 -SC \x9a -CI \x9b -ST \x9c -OC \x9d -PM \x9e -AC \x9f -NS \xa0 -A; \xa1 -'( \xa2 -L/ \xa3 -Cu \xa4 -L< \xa5 -S' \xa6 -SE \xa7 -': \xa8 -S< \xa9 -S, \xaa -T< \xab -Z' \xac --- \xad -Z< \xae -Z. \xaf -DG \xb0 -a; \xb1 -'; \xb2 -l/ \xb3 -'' \xb4 -l< \xb5 -s' \xb6 -'< \xb7 -', \xb8 -s< \xb9 -s, \xba -t< \xbb -z' \xbc -'" \xbd -z< \xbe -z. \xbf -R' \xc0 -A' \xc1 -A> \xc2 -A( \xc3 -A: \xc4 -L' \xc5 -C' \xc6 -C, \xc7 -C< \xc8 -E' \xc9 -E; \xca -E: \xcb -E< \xcc -I' \xcd -I> \xce -D< \xcf -D/ \xd0 -N' \xd1 -N< \xd2 -O' \xd3 -O> \xd4 -O" \xd5 -O: \xd6 -*X \xd7 -R< \xd8 -U0 \xd9 -U' \xda -U" \xdb -U: \xdc -Y' \xdd -T, \xde -ss \xdf -r' \xe0 -a' \xe1 -a> \xe2 -a( \xe3 -a: \xe4 -l' \xe5 -c' \xe6 -c, \xe7 -c< \xe8 -e' \xe9 -e; \xea -e: \xeb -e< \xec -i' \xed -i> \xee -d< \xef -d/ \xf0 -n' \xf1 -n< \xf2 -o' \xf3 -o> \xf4 -o" \xf5 -o: \xf6 --: \xf7 -r< \xf8 -u0 \xf9 -u' \xfa -u" \xfb -u: \xfc -y' \xfd -t, \xfe -'. \xff diff --git a/share/colldef/map.ISO8859-4 b/share/colldef/map.ISO8859-4 deleted file mode 100644 index 8bbeb57ea1dc..000000000000 --- a/share/colldef/map.ISO8859-4 +++ /dev/null @@ -1,175 +0,0 @@ -# $FreeBSD$ -NU \x00 -SH \x01 -SX \x02 -EX \x03 -ET \x04 -EQ \x05 -AK \x06 -BL \x07 -BS \x08 -HT \x09 -LF \x0a -VT \x0b -FF \x0c -CR \x0d -SO \x0e -SI \x0f -DL \x10 -D1 \x11 -D2 \x12 -D3 \x13 -D4 \x14 -NK \x15 -SY \x16 -EB \x17 -CN \x18 -EM \x19 -SB \x1a -EC \x1b -FS \x1c -GS \x1d -RS \x1e -US \x1f -SP \x20 -Nb \x23 -DO \x24 -At \x40 -<( \x5b -// \x5c -)> \x5d -'> \x5e -'! \x60 -(! \x7b -!! \x7c -!) \x7d -'? \x7e -DT \x7f -PA \x80 -HO \x81 -BH \x82 -NH \x83 -IN \x84 -NL \x85 -SA \x86 -ES \x87 -HS \x88 -HJ \x89 -VS \x8a -PD \x8b -PU \x8c -RI \x8d -S2 \x8e -S3 \x8f -DC \x90 -P1 \x91 -P2 \x92 -TS \x93 -CC \x94 -MW \x95 -SG \x96 -EG \x97 -SS \x98 -GC \x99 -SC \x9a -CI \x9b -ST \x9c -OC \x9d -PM \x9e -AC \x9f -NS \xa0 -A; \xa1 -kk \xa2 -R, \xa3 -Cu \xa4 -I? \xa5 -L, \xa6 -SE \xa7 -': \xa8 -S< \xa9 -E- \xaa -G, \xab -T/ \xac --- \xad -Z< \xae -'m \xaf -DG \xb0 -a; \xb1 -'; \xb2 -r, \xb3 -'' \xb4 -i? \xb5 -l, \xb6 -'< \xb7 -', \xb8 -s< \xb9 -e- \xba -g, \xbb -t/ \xbc -NG \xbd -z< \xbe -ng \xbf -A- \xc0 -A' \xc1 -A> \xc2 -A? \xc3 -A: \xc4 -AA \xc5 -AE \xc6 -I; \xc7 -C< \xc8 -E' \xc9 -E; \xca -E: \xcb -E. \xcc -I' \xcd -I> \xce -I- \xcf -D/ \xd0 -N, \xd1 -O- \xd2 -K, \xd3 -O> \xd4 -O? \xd5 -O: \xd6 -*X \xd7 -O/ \xd8 -U; \xd9 -U' \xda -U> \xdb -U: \xdc -U? \xdd -U- \xde -ss \xdf -a- \xe0 -a' \xe1 -a> \xe2 -a? \xe3 -a: \xe4 -aa \xe5 -ae \xe6 -i; \xe7 -c< \xe8 -e' \xe9 -e; \xea -e: \xeb -e. \xec -i' \xed -i> \xee -i- \xef -d/ \xf0 -n, \xf1 -o- \xf2 -k, \xf3 -o> \xf4 -o? \xf5 -o: \xf6 --: \xf7 -o/ \xf8 -u; \xf9 -u' \xfa -u> \xfb -u: \xfc -u? \xfd -u- \xfe -'. \xff diff --git a/share/colldef/map.ISO8859-5 b/share/colldef/map.ISO8859-5 deleted file mode 100644 index 230b559c659b..000000000000 --- a/share/colldef/map.ISO8859-5 +++ /dev/null @@ -1,175 +0,0 @@ -# $FreeBSD$ -NU \x00 -SH \x01 -SX \x02 -EX \x03 -ET \x04 -EQ \x05 -AK \x06 -BL \x07 -BS \x08 -HT \x09 -LF \x0a -VT \x0b -FF \x0c -CR \x0d -SO \x0e -SI \x0f -DL \x10 -D1 \x11 -D2 \x12 -D3 \x13 -D4 \x14 -NK \x15 -SY \x16 -EB \x17 -CN \x18 -EM \x19 -SB \x1a -EC \x1b -FS \x1c -GS \x1d -RS \x1e -US \x1f -SP \x20 -Nb \x23 -DO \x24 -At \x40 -<( \x5b -// \x5c -)> \x5d -'> \x5e -'! \x60 -(! \x7b -!! \x7c -!) \x7d -'? \x7e -DT \x7f -PA \x80 -HO \x81 -BH \x82 -NH \x83 -IN \x84 -NL \x85 -SA \x86 -ES \x87 -HS \x88 -HJ \x89 -VS \x8a -PD \x8b -PU \x8c -RI \x8d -S2 \x8e -S3 \x8f -DC \x90 -P1 \x91 -P2 \x92 -TS \x93 -CC \x94 -MW \x95 -SG \x96 -EG \x97 -SS \x98 -GC \x99 -SC \x9a -CI \x9b -ST \x9c -OC \x9d -PM \x9e -AC \x9f -NS \xa0 -IO \xa1 -D% \xa2 -G% \xa3 -IE \xa4 -DS \xa5 -II \xa6 -YI \xa7 -J% \xa8 -LJ \xa9 -NJ \xaa -Ts \xab -KJ \xac --- \xad -V% \xae -DZ \xaf -A= \xb0 -B= \xb1 -V= \xb2 -G= \xb3 -D= \xb4 -E= \xb5 -Z% \xb6 -Z= \xb7 -I= \xb8 -J= \xb9 -K= \xba -L= \xbb -M= \xbc -N= \xbd -O= \xbe -P= \xbf -R= \xc0 -S= \xc1 -T= \xc2 -U= \xc3 -F= \xc4 -H= \xc5 -C= \xc6 -C% \xc7 -S% \xc8 -Sc \xc9 -=" \xca -Y= \xcb -%" \xcc -JE \xcd -JU \xce -JA \xcf -a= \xd0 -b= \xd1 -v= \xd2 -g= \xd3 -d= \xd4 -e= \xd5 -z% \xd6 -z= \xd7 -i= \xd8 -j= \xd9 -k= \xda -l= \xdb -m= \xdc -n= \xdd -o= \xde -p= \xdf -r= \xe0 -s= \xe1 -t= \xe2 -u= \xe3 -f= \xe4 -h= \xe5 -c= \xe6 -c% \xe7 -s% \xe8 -sc \xe9 -=' \xea -y= \xeb -%' \xec -je \xed -ju \xee -ja \xef -N0 \xf0 -io \xf1 -d% \xf2 -g% \xf3 -ie \xf4 -ds \xf5 -ii \xf6 -yi \xf7 -j% \xf8 -lj \xf9 -nj \xfa -ts \xfb -kj \xfc -SE \xfd -v% \xfe -dz \xff diff --git a/share/colldef/ru_RU.CP866.src b/share/colldef/ru_RU.CP866.src deleted file mode 100644 index 2fc2d20835c3..000000000000 --- a/share/colldef/ru_RU.CP866.src +++ /dev/null @@ -1,39 +0,0 @@ -# CP866 (backward compatible with ASCII) -# -# $FreeBSD$ -# -charmap map.CP866 -order \ -# controls - <NU>;...;<US>;\ -# - <NS>;<SP>;!;\";<Nb>;<DO>;\ - %;&;';\(;\);*;+;<-:>;\,;-;.;/;\ -# digits - 0;1;(2,<2S>);3;...;9;\ -# - :;\;;\<;<=<>;=;</>=>;>;?;<Co>;<At>;\ -# capital - A;...;Z;\ - <A=>;<B=>;<V=>;<G=>;<D=>;<E=>;<IO>;<Z%>;<Z=>;\ - <I=>;<J=>;<K=>;<L=>;<M=>;<N=>;<O=>;<P=>;<R=>;\ - <S=>;<T=>;<U=>;<F=>;<H=>;<C=>;<C%>;<S%>;<Sc>;\ - <=">;<Y=>;<%">;<JE>;<JU>;<JA>;\ -# - [;\\;];^;_;`;\ -# small - a;...;z;\ - <a=>;<b=>;<v=>;<g=>;<d=>;<e=>;<io>;<z%>;<z=>;\ - <i=>;<j=>;<k=>;<l=>;<m=>;<n=>;<o=>;<p=>;<r=>;\ - <s=>;<t=>;<u=>;<f=>;<h=>;<c=>;<c%>;<s%>;<sc>;\ - <='>;<y=>;<%'>;<je>;<ju>;<ja>;\ -# - \{;|;\};~;<.M>;<DG>;<DT>;\ -# - <sb>;<RT>;<?2>;<Iu>;<Il>;\ - <hh>;<HH>;<vv>;<VV>;<dr>;<dR>;<Dr>;<DR>;\ - <dl>;<dL>;<Dl>;<LD>;<ur>;<uR>;<Ur>;<UR>;\ - <ul>;<uL>;<Ul>;<UL>;<vr>;<vR>;<Vr>;<VR>;\ - <vl>;<vL>;<Vl>;<VL>;<dh>;<dH>;<Dh>;<DH>;\ - <uh>;<uH>;<Uh>;<UH>;<vh>;<vH>;<Vh>;<VH>;\ - <TB>;<LB>;<FB>;<lB>;<RB>;<.S>;<:S>;<?S>;<fS> diff --git a/share/colldef/ru_RU.KOI8-R.src b/share/colldef/ru_RU.KOI8-R.src deleted file mode 100644 index 3a67bc4e39fb..000000000000 --- a/share/colldef/ru_RU.KOI8-R.src +++ /dev/null @@ -1,39 +0,0 @@ -# koi8-r (backward compatible with ASCII) -# -# $FreeBSD$ -# -charmap map.KOI8-R -order \ -# controls - <NU>;...;<US>;\ -# - <NS>;<SP>;!;\";<Nb>;<DO>;\ - %;&;';\(;\);*;+;<-:>;\,;-;.;/;\ -# digits - 0;1;(2,<2S>);3;...;9;\ -# - :;\;;\<;<=<>;=;</>=>;>;?;<Co>;<At>;\ -# capital - A;...;Z;\ - <A=>;<B=>;<V=>;<G=>;<D=>;<E=>;<IO>;<Z%>;<Z=>;\ - <I=>;<J=>;<K=>;<L=>;<M=>;<N=>;<O=>;<P=>;<R=>;\ - <S=>;<T=>;<U=>;<F=>;<H=>;<C=>;<C%>;<S%>;<Sc>;\ - <=">;<Y=>;<%">;<JE>;<JU>;<JA>;\ -# - [;\\;];^;_;`;\ -# small - a;...;z;\ - <a=>;<b=>;<v=>;<g=>;<d=>;<e=>;<io>;<z%>;<z=>;\ - <i=>;<j=>;<k=>;<l=>;<m=>;<n=>;<o=>;<p=>;<r=>;\ - <s=>;<t=>;<u=>;<f=>;<h=>;<c=>;<c%>;<s%>;<sc>;\ - <='>;<y=>;<%'>;<je>;<ju>;<ja>;\ -# - \{;|;\};~;<.M>;<DG>;<DT>;\ -# - <sb>;<RT>;<?2>;<Iu>;<Il>;\ - <hh>;<HH>;<vv>;<VV>;<dr>;<dR>;<Dr>;<DR>;\ - <dl>;<dL>;<Dl>;<LD>;<ur>;<uR>;<Ur>;<UR>;\ - <ul>;<uL>;<Ul>;<UL>;<vr>;<vR>;<Vr>;<VR>;\ - <vl>;<vL>;<Vl>;<VL>;<dh>;<dH>;<Dh>;<DH>;\ - <uh>;<uH>;<Uh>;<UH>;<vh>;<vH>;<Vh>;<VH>;\ - <TB>;<LB>;<FB>;<lB>;<RB>;<.S>;<:S>;<?S>;<fS> diff --git a/share/doc/papers/jail/Makefile b/share/doc/papers/jail/Makefile deleted file mode 100644 index 174af30c374a..000000000000 --- a/share/doc/papers/jail/Makefile +++ /dev/null @@ -1,10 +0,0 @@ -# $FreeBSD$ -PRINTERDEVICE=ps -NODOCCOMPRESS=1 -VOLUME= papers -DOC= jail -SRCS= paper.ms -MACROS= -ms -U -OBJS= implementation.ms mgt.ms future.ms - -.include <bsd.doc.mk> diff --git a/share/doc/papers/jail/future.ms b/share/doc/papers/jail/future.ms deleted file mode 100644 index 01c325d4d19c..000000000000 --- a/share/doc/papers/jail/future.ms +++ /dev/null @@ -1,104 +0,0 @@ -.\" -.\" $FreeBSD$ -.\" -.NH -Future Directions -.PP -The jail facility has already been deployed in numerous capacities and -a few opportunities for improvement have manifested themselves. -.NH 2 -Improved Virtualisation -.PP -As it stands, the jail code provides a strict subset of system resources -to the jail environment, based on access to processes, files, network -resources, and privileged services. -Virtualisation, or making the jail environments appear to be fully -functional FreeBSD systems, allows maximum application support and the -ability to offer a wide range of services within a jail environment. -However, there are a number of limitations on the degree of virtualisation -in the current code, and removing these limitations will enhance the -ability to offer services in a jail environment. -Two areas that deserve greater attention are the virtualisation of -network resources, and management of scheduling resources. -.PP -Currently, a single IP address may be allocated to each jail, and all -communication from the jail is limited to that IP address. -In particular, these addresses are IPv4 addresses. -There has been substantial interest in improving interface virtualisation, -allowing one or more addresses to be assigned to an interface, and -removing the requirement that the address be an IPv4 address, allowing -the use of IPv6. -Also, access to raw sockets is currently prohibited, as the current -implementation of raw sockets allows access to raw IP packets associated -with all interfaces. -Limiting the scope of the raw socket would allow its safe use within -a jail, re-enabling support for ping, and other network debugging and -evaluation tools. -.PP -Another area of great interest to the current consumers of the jail code -is the ability to limit the impact of one jail on the CPU resources -available for other jails. -Specifically, this would require that the jail of a process play a rule in -its scheduling parameters. -Prior work in the area of lottery scheduling, currently available as -patches on FreeBSD 2.2.x, might be leveraged to allow some degree of -partitioning between jail environments \s-2[LOTTERY1] [LOTTERY2]\s+2. -However, as the current scheduling mechanism is targeted at time -sharing, and FreeBSD does not currently support real time preemption -of processes in kernel, complete partitioning is not possible within the -current framework. -.NH 2 -Improved Management -.PP -Management of jail environments is currently somewhat ad hoc--creating -and starting jails is a well-documented procedure, but day-to-day -management of jails, as well as special case procedures such as shutdown, -are not well analysed and documented. -The current kernel process management infrastructure does not have the -ability to manage pools of processes in a jail-centric way. -For example, it is possible to, within a jail, deliver a signal to all -processes in a jail, but it is not possibly to atomically target all -processes within a jail from outside of the jail. -If the jail code is to effectively limit the behaviour of a jail, the -ability to shut it down cleanly is paramount. -Similarly, shutting down a jail cleanly from within is also not well -defined, the traditional shutdown utilities having been written with -a host environment in mind. -This suggests a number of improvements, both in the kernel and in the -user-land utility set. -.PP -First, the ability to address kernel-centric management mechanisms at -jails is important. -One way in which this might be done is to assign a unique jail id, not -unlike a process id or process group id, at jail creation time. -A new jailkill() syscall would permit the direction of signals to -specific jailids, allowing for the effective termination of all processes -in the jail. -A unique jailid could also supplant the hostname as the unique -identifier for a jail, allowing the hostname to be changed by the -processes in the jail without interfering with jail management. -.PP -More carefully defining the user-land semantics of a jail during startup -and shutdown is also important. -The traditional FreeBSD environment makes use of an init process to -bring the system up during the boot process, and to assist in shutdown. -A similar technique might be used for jail, in effect a jailinit, -formulated to handle the clean startup and shutdown, including calling -out to jail-local /etc/rc.shutdown, and other useful shutdown functions. -A jailinit would also present a central location for delivering -management requests to within a jail from the host environment, allowing -the host environment to request the shutdown of the jail cleanly, before -resorting to terminating processes, in the same style as the host -environment shutting down before killing all processes and halting the -kernel. -.PP -Improvements in the host environment would also assist in improving -jail management, possibly including automated runtime jail management tools, -tools to more easily construct the per-jail file system area, and -include jail shutdown as part of normal system shutdown. -.PP -These improvements in the jail framework would improve both raw -functionality and usability from a management perspective. -The jail code has raised significant interest in the FreeBSD community, -and it is hoped that this type of improved functionality will be -available in upcoming releases of FreeBSD. diff --git a/share/doc/papers/jail/implementation.ms b/share/doc/papers/jail/implementation.ms deleted file mode 100644 index eafc8f25c9c7..000000000000 --- a/share/doc/papers/jail/implementation.ms +++ /dev/null @@ -1,126 +0,0 @@ -.\" -.\" $FreeBSD$ -.\" -.NH -Implementation jail in the FreeBSD kernel. -.NH 2 -The jail(2) system call, allocation, refcounting and deallocation of -\fCstruct prison\fP. -.PP -The jail(2) system call is implemented as a non-optional system call -in FreeBSD. Other system calls are controlled by compile time options -in the kernel configuration file, but due to the minute footprint of -the jail implementation, it was decided to make it a standard -facility in FreeBSD. -.PP -The implementation of the system call is straightforward: a data structure -is allocated and populated with the arguments provided. The data structure -is attached to the current process' \fCstruct proc\fP, its reference count -set to one and a call to the -chroot(2) syscall implementation completes the task. -.PP -Hooks in the code implementing process creation and destruction maintains -the reference count on the data structure and free it when the last reference -is lost. -Any new process created by a process in a jail will inherit a reference -to the jail, which effectively puts the new process in the same jail. -.PP -There is no way to modify the contents of the data structure describing -the jail after its creation, and no way to attach a process to an existing -jail if it was not created from the inside that jail. -.NH 2 -Fortification of the chroot(2) facility for filesystem name scoping. -.PP -A number of ways to escape the confines of a chroot(2)-created subscope -of the filesystem view have been identified over the years. -chroot(2) was never intended to be security mechanism as such, but even -then the ftp daemon largely depended on the security provided by -chroot(2) to provide the ``anonymous ftp'' access method. -.PP -Three classes of escape routes existed: recursive chroot(2) escapes, -``..'' based escapes and fchdir(2) based escapes. -All of these exploited the fact that chroot(2) didn't try sufficiently -hard to enforce the new root directory. -.PP -New code were added to detect and thwart these escapes, amongst -other things by tracking the directory of the first level of chroot(2) -experienced by a process and refusing backwards traversal across -this directory, as well as additional code to refuse chroot(2) if -file-descriptors were open referencing directories. -.NH 2 -Restriction of process visibility and interaction. -.PP -A macro was already in available in the kernel to determine if one process -could affect another process. This macro did the rather complex checking -of uid and gid values. It was felt that the complexity of the macro were -approaching the lower edge of IOCCC entrance criteria, and it was therefore -converted to a proper function named \fCp_trespass(p1, p2)\fP which does -all the previous checks and additionally checks the jail aspect of the access. -The check is implemented such that access fails if the origin process is jailed -but the target process is not in the same jail. -.PP -Process visibility is provided through two mechanisms in FreeBSD, -the \fCprocfs\fP file system and a sub-tree of the \fCsysctl\fP tree. -Both of these were modified to report only the processes in the same -jail to a jailed process. -.NH 2 -Restriction to one IP number. -.PP -Restricting TCP and UDP access to just one IP number was done almost -entirely in the code which manages ``protocol control blocks''. -When a jailed process binds to a socket, the IP number provided by -the process will not be used, instead the pre-configured IP number of -the jail is used. -.PP -BSD based TCP/IP network stacks sport a special interface, the loop-back -interface, which has the ``magic'' IP number 127.0.0.1. -This is often used by processes to contact servers on the local machine, -and consequently special handling for jails were needed. -To handle this case it was necessary to also intercept and modify the -behaviour of connection establishment, and when the 127.0.0.1 address -were seen from a jailed process, substitute the jails configured IP number. -.PP -Finally the APIs through which the network configuration and connection -state may be queried were modified to report only information relevant -to the configured IP number of a jailed process. -.NH 2 -Adding jail awareness to selected device drivers. -.PP -A couple of device drivers needed to be taught about jails, the ``pty'' -driver is one of them. The pty driver provides ``virtual terminals'' to -services like telnet, ssh, rlogin and X11 terminal window programs. -Therefore jails need access to the pty driver, and code had to be added -to enforce that a particular virtual terminal were not accessed from more -than one jail at the same time. -.NH 2 -General restriction of super-users powers for jailed super-users. -.PP -This item proved to be the simplest but most tedious to implement. -Tedious because a manual review of all places where the kernel allowed -the super user special powers were called for, -simple because very few places were required to let a jailed root through. -Of the approximately 260 checks in the FreeBSD 4.0 kernel, only -about 35 will let a jailed root through. -.PP -Since the default is for jailed roots to not receive privilege, new -code or drivers in the FreeBSD kernel are automatically jail-aware: they -will refuse jailed roots privilege. -The other part of this protection comes from the fact that a jailed -root cannot create new device nodes with the mknod(2) systemcall, so -unless the machine administrator creates device nodes for a particular -device inside the jails filesystem tree, the driver in effect does -not exist in the jail. -.PP -As a side-effect of this work the suser(9) API were cleaned up and -extended to cater for not only the jail facility, but also to make room -for future partitioning facilities. -.NH 2 -Implementation statistics -.PP -The change of the suser(9) API modified approx 350 source lines -distributed over approx. 100 source files. The vast majority of -these changes were generated automatically with a script. -.PP -The implementation of the jail facility added approx 200 lines of -code in total, distributed over approx. 50 files. and about 200 lines -in two new kernel files. diff --git a/share/doc/papers/jail/jail01.eps b/share/doc/papers/jail/jail01.eps deleted file mode 100644 index ffcfa30386f1..000000000000 --- a/share/doc/papers/jail/jail01.eps +++ /dev/null @@ -1,234 +0,0 @@ -%!PS-Adobe-2.0 EPSF-2.0 -%%Title: jail01.eps -%%Creator: fig2dev Version 3.2 Patchlevel 1 -%%CreationDate: Fri Mar 24 20:37:59 2000 -%%For: $FreeBSD$ -%%Orientation: Portrait -%%BoundingBox: 0 0 425 250 -%%Pages: 0 -%%BeginSetup -%%EndSetup -%%Magnification: 1.0000 -%%EndComments -/$F2psDict 200 dict def -$F2psDict begin -$F2psDict /mtrx matrix put -/col-1 {0 setgray} bind def -/col0 {0.000 0.000 0.000 srgb} bind def -/col1 {0.000 0.000 1.000 srgb} bind def -/col2 {0.000 1.000 0.000 srgb} bind def -/col3 {0.000 1.000 1.000 srgb} bind def -/col4 {1.000 0.000 0.000 srgb} bind def -/col5 {1.000 0.000 1.000 srgb} bind def -/col6 {1.000 1.000 0.000 srgb} bind def -/col7 {1.000 1.000 1.000 srgb} bind def -/col8 {0.000 0.000 0.560 srgb} bind def -/col9 {0.000 0.000 0.690 srgb} bind def -/col10 {0.000 0.000 0.820 srgb} bind def -/col11 {0.530 0.810 1.000 srgb} bind def -/col12 {0.000 0.560 0.000 srgb} bind def -/col13 {0.000 0.690 0.000 srgb} bind def -/col14 {0.000 0.820 0.000 srgb} bind def -/col15 {0.000 0.560 0.560 srgb} bind def -/col16 {0.000 0.690 0.690 srgb} bind def -/col17 {0.000 0.820 0.820 srgb} bind def -/col18 {0.560 0.000 0.000 srgb} bind def -/col19 {0.690 0.000 0.000 srgb} bind def -/col20 {0.820 0.000 0.000 srgb} bind def -/col21 {0.560 0.000 0.560 srgb} bind def -/col22 {0.690 0.000 0.690 srgb} bind def -/col23 {0.820 0.000 0.820 srgb} bind def -/col24 {0.500 0.190 0.000 srgb} bind def -/col25 {0.630 0.250 0.000 srgb} bind def -/col26 {0.750 0.380 0.000 srgb} bind def -/col27 {1.000 0.500 0.500 srgb} bind def -/col28 {1.000 0.630 0.630 srgb} bind def -/col29 {1.000 0.750 0.750 srgb} bind def -/col30 {1.000 0.880 0.880 srgb} bind def -/col31 {1.000 0.840 0.000 srgb} bind def - -end -save --117.0 298.0 translate -1 -1 scale - -/cp {closepath} bind def -/ef {eofill} bind def -/gr {grestore} bind def -/gs {gsave} bind def -/sa {save} bind def -/rs {restore} bind def -/l {lineto} bind def -/m {moveto} bind def -/rm {rmoveto} bind def -/n {newpath} bind def -/s {stroke} bind def -/sh {show} bind def -/slc {setlinecap} bind def -/slj {setlinejoin} bind def -/slw {setlinewidth} bind def -/srgb {setrgbcolor} bind def -/rot {rotate} bind def -/sc {scale} bind def -/sd {setdash} bind def -/ff {findfont} bind def -/sf {setfont} bind def -/scf {scalefont} bind def -/sw {stringwidth} bind def -/tr {translate} bind def -/tnt {dup dup currentrgbcolor - 4 -2 roll dup 1 exch sub 3 -1 roll mul add - 4 -2 roll dup 1 exch sub 3 -1 roll mul add - 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} - bind def -/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul - 4 -2 roll mul srgb} bind def -/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def -/$F2psEnd {$F2psEnteredState restore end} def -%%EndProlog - -$F2psBegin -10 setmiterlimit -n -1000 5962 m -1000 -1000 l 10022 -1000 l 10022 5962 l cp clip - 0.06000 0.06000 sc -/Courier-BoldOblique ff 180.00 scf sf -7725 3600 m -gs 1 -1 sc (10.0.0.2) dup sw pop neg 0 rm col0 sh gr -% Polyline -15.000 slw -n 9000 3300 m 9000 4275 l gs col0 s gr -% Polyline -2 slc -n 7875 3225 m 7800 3225 l gs col0 s gr -% Polyline -0 slc -n 7875 4125 m 7800 4125 l gs col0 s gr -% Polyline -n 7875 3225 m 7875 4425 l gs col0 s gr -% Polyline -n 7875 3825 m 7800 3825 l gs col0 s gr -% Polyline -n 7875 3525 m 7800 3525 l gs col0 s gr -% Polyline -n 8175 3825 m 7875 3825 l gs col0 s gr -% Polyline -2 slc -n 7875 4425 m 7800 4425 l gs col0 s gr -/Courier-Bold ff 180.00 scf sf -8700 3900 m -gs 1 -1 sc (fxp0) dup sw pop neg 0 rm col0 sh gr -% Polyline -0 slc -7.500 slw -n 2925 1425 m 3075 1425 l gs col0 s gr -% Polyline -15.000 slw -n 2475 1350 m 2472 1347 l 2465 1342 l 2453 1334 l 2438 1323 l 2420 1311 l - 2401 1299 l 2383 1289 l 2366 1281 l 2351 1275 l 2338 1274 l - 2325 1275 l 2314 1279 l 2303 1285 l 2291 1293 l 2278 1303 l - 2264 1314 l 2250 1326 l 2236 1339 l 2222 1353 l 2209 1366 l - 2198 1379 l 2188 1391 l 2181 1403 l 2177 1414 l 2175 1425 l - 2177 1436 l 2181 1447 l 2188 1459 l 2198 1471 l 2209 1484 l - 2222 1497 l 2236 1511 l 2250 1524 l 2264 1536 l 2278 1547 l - 2291 1557 l 2303 1565 l 2314 1571 l 2325 1575 l 2338 1576 l - 2351 1575 l 2366 1569 l 2383 1561 l 2401 1551 l 2420 1539 l - 2438 1527 l 2453 1516 l 2465 1508 l 2472 1503 l 2475 1500 l gs col0 s gr -/Courier-Bold ff 180.00 scf sf -2550 1500 m -gs 1 -1 sc (lo0) col0 sh gr -/Courier-BoldOblique ff 180.00 scf sf -3075 1500 m -gs 1 -1 sc (127.0.0.1) col0 sh gr -% Polyline -7.500 slw -n 2100 3525 m 2250 3525 l gs col0 s gr -% Polyline -n 2550 2100 m 2250 2400 l 2250 4500 l 2550 4800 l gs col0 s gr -/Courier-Bold ff 180.00 scf sf -1950 3600 m -gs 1 -1 sc (/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -2550 3900 m -gs 1 -1 sc (jail_1/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -2550 4200 m -gs 1 -1 sc (jail_2/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -2550 4500 m -gs 1 -1 sc (jail_3/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -2550 2400 m -gs 1 -1 sc (dev/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -2550 2700 m -gs 1 -1 sc (etc/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -2550 3000 m -gs 1 -1 sc (usr/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -2550 3300 m -gs 1 -1 sc (var/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -2550 3600 m -gs 1 -1 sc (home/) col0 sh gr -% Polyline -n 3375 3825 m 3900 3825 l 4950 1800 l 5100 1800 l gs col0 s gr -% Polyline -n 3375 4125 m 3900 4125 l 4950 3900 l 5100 3900 l gs col0 s gr -% Polyline -n 5400 900 m 5100 1200 l 5100 2400 l 5400 2700 l gs col0 s gr -% Polyline -n 5400 3000 m 5100 3300 l 5100 4500 l 5400 4800 l gs col0 s gr -% Polyline -n 4650 825 m 4650 2775 l 6675 2775 l 6675 3375 l 7950 3375 l 7950 825 l - cp gs col0 s gr -% Polyline -n 4650 2775 m 4650 4950 l 6300 4950 l 6300 3675 l 7950 3675 l 7950 3375 l - 6675 3375 l 6675 2775 l cp gs col0 s gr -/Courier-Bold ff 180.00 scf sf -5400 1200 m -gs 1 -1 sc (dev/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -5400 1500 m -gs 1 -1 sc (etc/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -5400 1800 m -gs 1 -1 sc (usr/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -5400 2100 m -gs 1 -1 sc (var/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -5400 2400 m -gs 1 -1 sc (home/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -5400 3300 m -gs 1 -1 sc (dev/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -5400 3600 m -gs 1 -1 sc (etc/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -5400 3900 m -gs 1 -1 sc (usr/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -5400 4200 m -gs 1 -1 sc (var/) col0 sh gr -/Courier-Bold ff 180.00 scf sf -5400 4500 m -gs 1 -1 sc (home/) col0 sh gr -/Courier-BoldOblique ff 180.00 scf sf -7725 3300 m -gs 1 -1 sc (10.0.0.1) dup sw pop neg 0 rm col0 sh gr -/Courier-BoldOblique ff 180.00 scf sf -7725 4500 m -gs 1 -1 sc (10.0.0.5) dup sw pop neg 0 rm col0 sh gr -/Courier-BoldOblique ff 180.00 scf sf -7725 4200 m -gs 1 -1 sc (10.0.0.4) dup sw pop neg 0 rm col0 sh gr -/Courier-BoldOblique ff 180.00 scf sf -7725 3900 m -gs 1 -1 sc (10.0.0.3) dup sw pop neg 0 rm col0 sh gr -% Polyline -15.000 slw -n 9000 3825 m 8775 3825 l gs col0 s gr -$F2psEnd -rs diff --git a/share/doc/papers/jail/jail01.fig b/share/doc/papers/jail/jail01.fig deleted file mode 100644 index d4ef1655e195..000000000000 --- a/share/doc/papers/jail/jail01.fig +++ /dev/null @@ -1,86 +0,0 @@ -#FIG 3.2 -# $FreeBSD$ -Landscape -Center -Inches -A4 -100.00 -Single --2 -1200 2 -6 7725 3150 9075 4500 -6 8700 3225 9075 4350 -2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 0 0 2 - 9000 3825 8775 3825 -2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 0 0 2 - 9000 3300 9000 4275 --6 -2 1 0 2 0 7 100 0 -1 0.000 0 2 -1 0 0 2 - 7875 3225 7800 3225 -2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 0 0 2 - 7875 4125 7800 4125 -2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 0 0 2 - 7875 3225 7875 4425 -2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 0 0 2 - 7875 3825 7800 3825 -2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 0 0 2 - 7875 3525 7800 3525 -2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 0 0 2 - 8175 3825 7875 3825 -2 1 0 2 0 7 100 0 -1 0.000 0 2 -1 0 0 2 - 7875 4425 7800 4425 -4 2 0 100 0 14 12 0.0000 4 180 420 8700 3900 fxp0\001 --6 -6 2100 1200 4050 1650 -2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 - 2925 1425 3075 1425 -3 2 0 2 0 7 100 0 -1 0.000 0 0 0 5 - 2475 1350 2325 1275 2175 1425 2325 1575 2475 1500 - 0.000 -1.000 -1.000 -1.000 0.000 -4 0 0 100 0 14 12 0.0000 4 135 315 2550 1500 lo0\001 -4 0 0 100 0 15 12 0.0000 4 135 945 3075 1500 127.0.0.1\001 --6 -6 1950 2100 3300 4800 -2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 - 2100 3525 2250 3525 -2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 4 - 2550 2100 2250 2400 2250 4500 2550 4800 -4 0 0 100 0 14 12 0.0000 4 150 105 1950 3600 /\001 -4 0 0 100 0 14 12 0.0000 4 180 735 2550 3900 jail_1/\001 -4 0 0 100 0 14 12 0.0000 4 180 735 2550 4200 jail_2/\001 -4 0 0 100 0 14 12 0.0000 4 180 735 2550 4500 jail_3/\001 -4 0 0 100 0 14 12 0.0000 4 165 420 2550 2400 dev/\001 -4 0 0 100 0 14 12 0.0000 4 150 420 2550 2700 etc/\001 -4 0 0 100 0 14 12 0.0000 4 150 420 2550 3000 usr/\001 -4 0 0 100 0 14 12 0.0000 4 150 420 2550 3300 var/\001 -4 0 0 100 0 14 12 0.0000 4 165 525 2550 3600 home/\001 --6 -2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 4 - 3375 3825 3900 3825 4950 1800 5100 1800 -2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 4 - 3375 4125 3900 4125 4950 3900 5100 3900 -2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 4 - 5400 900 5100 1200 5100 2400 5400 2700 -2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 4 - 5400 3000 5100 3300 5100 4500 5400 4800 -2 3 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 7 - 4650 825 4650 2775 6675 2775 6675 3375 7950 3375 7950 825 - 4650 825 -2 3 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 9 - 4650 2775 4650 4950 6300 4950 6300 3675 7950 3675 7950 3375 - 6675 3375 6675 2775 4650 2775 -4 0 0 100 0 14 12 0.0000 4 165 420 5400 1200 dev/\001 -4 0 0 100 0 14 12 0.0000 4 150 420 5400 1500 etc/\001 -4 0 0 100 0 14 12 0.0000 4 150 420 5400 1800 usr/\001 -4 0 0 100 0 14 12 0.0000 4 150 420 5400 2100 var/\001 -4 0 0 100 0 14 12 0.0000 4 165 525 5400 2400 home/\001 -4 0 0 100 0 14 12 0.0000 4 165 420 5400 3300 dev/\001 -4 0 0 100 0 14 12 0.0000 4 150 420 5400 3600 etc/\001 -4 0 0 100 0 14 12 0.0000 4 150 420 5400 3900 usr/\001 -4 0 0 100 0 14 12 0.0000 4 150 420 5400 4200 var/\001 -4 0 0 100 0 14 12 0.0000 4 165 525 5400 4500 home/\001 -4 2 0 100 0 15 12 0.0000 4 135 840 7725 3300 10.0.0.1\001 -4 2 0 100 0 15 12 0.0000 4 135 840 7725 4500 10.0.0.5\001 -4 2 0 100 0 15 12 0.0000 4 135 840 7725 4200 10.0.0.4\001 -4 2 0 100 0 15 12 0.0000 4 135 840 7725 3900 10.0.0.3\001 -4 2 0 100 0 15 12 0.0000 4 135 840 7725 3600 10.0.0.2\001 diff --git a/share/doc/papers/jail/mgt.ms b/share/doc/papers/jail/mgt.ms deleted file mode 100644 index b9b5b317f82b..000000000000 --- a/share/doc/papers/jail/mgt.ms +++ /dev/null @@ -1,218 +0,0 @@ -.\" -.\" $FreeBSD$ -.\" -.NH -Managing Jails and the Jail File System Environment -.NH 2 -Creating a Jail Environment -.PP -While the jail(2) call could be used in a number of ways, the expected -configuration creates a complete FreeBSD installation for each jail. -This includes copies of all relevant system binaries, data files, and its -own \fC/etc\fP directory. -Such a configuration maximises the independence of various jails, -and reduces the chances of interference between jails being possible, -especially when it is desirable to provide root access within a jail to -a less trusted user. -.PP -On a box making use of the jail facility, we refer to two types of -environment: the host environment, and the jail environment. -The host environment is the real operating system environment, which is -used to configure interfaces, and start up the jails. -There are then one or more jail environments, effectively virtual -FreeBSD machines. -When configuring Jail for use, it is necessary to configure both the -host and jail environments to prevent overlap. -.PP -As jailed virtual machines are generally bound to an IP address configured -using the normal IP alias mechanism, those jail IP addresses are also -accessible to host environment applications to use. -If the accessibility of some host applications in the jail environment is -not desirable, it is necessary to configure those applications to only -listen on appropriate addresses. -.PP -In most of the production environments where jail is currently in use, -one IP address is allocated to the host environment, and then a number -are allocated to jail boxes, with each jail box receiving a unique IP. -In this situation, it is sufficient to configure the networking applications -on the host to listen only on the host IP. -Generally, this consists of specifying the appropriate IP address to be -used by inetd and SSH, and disabling applications that are not capable -of limiting their address scope, such as sendmail, the port mapper, and -syslogd. -Other third party applications that have been installed on the host must also be -configured in this manner, or users connecting to the jailbox will -discover the host environment service, unless the jailbox has -specifically bound a service to that port. -In some situations, this can actually be the desirable behaviour. -.PP -The jail environments must also be custom-configured. -This consists of building and installing a miniature version of the -FreeBSD file system tree off of a subdirectory in the host environment, -usually \fC/usr/jail\fP, or \fC/data/jail\fP, with a subdirectory per jail. -Appropriate instructions for generating this tree are included in the -jail(8) man page, but generally this process may be automated using the -FreeBSD build environment. -.PP -One notable difference from the default FreeBSD install is that only -a limited set of device nodes should be created. -MAKEDEV(8) has been modified to accept a ``jail'' argument that creates -the correct set of nodes. -.PP -To improve storage efficiency, a fair number of the binaries in the system tree -may be deleted, as they are not relevant in a jail environment. -This includes the kernel, boot loader, and related files, as well as -hardware and network configuration tools. -.PP -After the creation of the jail tree, the easiest way to configure it is -to start up the jail in single-user mode. -The sysinstall admin tool may be used to help with the task, although -it is not installed by default as part of the system tree. -These tools should be run in the jail environment, or they will affect -the host environment's configuration. -.DS -.ft C -.ps -2 -# mkdir /data/jail/192.168.11.100/stand -# cp /stand/sysinstall /data/jail/192.168.11.100/stand -# jail /data/jail/192.168.11.100 testhostname 192.168.11.100 \e - /bin/sh -.ps +2 -.R -.DE -.PP -After running the jail command, the shell is now within the jail environment, -and all further commands -will be limited to the scope of the jail until the shell exits. -If the network alias has not yet been configured, then the jail will be -unable to access the network. -.PP -The startup configuration of the jail environment may be configured so -as to quell warnings from services that cannot run in the jail. -Also, any per-system configuration required for a normal FreeBSD system -is also required for each jailbox. -Typically, this includes: -.IP "" 5n -\(bu Create empty /etc/fstab -.IP -\(bu Disable portmapper -.IP -\(bu Run newaliases -.IP -\(bu Disabling interface configuration -.IP -\(bu Configure the resolver -.IP -\(bu Set root password -.IP -\(bu Set timezone -.IP -\(bu Add any local accounts -.IP -\(bu Install any packets -.NH 2 -Starting Jails -.PP -Jails are typically started by executing their /etc/rc script in much -the same manner a shell was started in the previous section. -Before starting the jail, any relevant networking configuration -should also be performed. -Typically, this involves adding an additional IP address to the -appropriate network interface, setting network properties for the -IP address using IP filtering, forwarding, and bandwidth shaping, -and mounting a process file system for the jail, if the ability to -debug processes from within the jail is desired. -.DS -.ft C -.ps -2 -# ifconfig ed0 inet add 192.168.11.100 netmask 255.255.255.255 -# mount -t procfs proc /data/jail/192.168.11.100/proc -# jail /data/jail/192.168.11.100 testhostname 192.168.11.100 \e - /bin/sh /etc/rc -.ps +2 -.ft P -.DE -.PP -A few warnings are generated for sysctl's that are not permitted -to be set within the jail, but the end result is a set of processes -in an isolated process environment, bound to a single IP address. -Normal procedures for accessing a FreeBSD machine apply: telneting in -through the network reveals a telnet prompt, login, and shell. -.DS -.ft C -.ps -2 -% ps ax - PID TT STAT TIME COMMAND - 228 ?? SsJ 0:18.73 syslogd - 247 ?? IsJ 0:00.05 inetd -wW - 249 ?? IsJ 0:28.43 cron - 252 ?? SsJ 0:30.46 sendmail: accepting connections on port 25 - 291 ?? IsJ 0:38.53 /usr/local/sbin/sshd -93694 ?? SJ 0:01.01 sshd: rwatson@ttyp0 (sshd) -93695 p0 SsJ 0:00.06 -csh (csh) -93700 p0 R+J 0:00.00 ps ax -.ps +2 -.ft P -.DE -.PP -It is immediately obvious that the environment is within a jailbox: there -is no init process, no kernel daemons, and a J flag is present beside all -processes indicating the presence of a jail. -.PP -As with any FreeBSD system, accounts may be created and deleted, -mail is delivered, logs are generated, packages may be added, and the -system may be hacked into if configured incorrectly, or running a buggy -version of a piece of software. -However, all of this happens strictly within the scope of the jail. -.NH 2 -Jail Management -.PP -Jail management is an interesting prospect, as there are two perspectives -from which a jail environment may be administered: from within the jail, -and from the host environment. -From within the jail, as described above, the process is remarkably similar -to any regular FreeBSD install, although certain actions are prohibited, -such as mounting file systems, modifying system kernel properties, etc. -The only area that really differs are that of shutting -the system down: the processes within the jail may deliver signals -between them, allowing all processes to be killed, but bringing the -system back up requires intervention from outside of the jailbox. -.PP -From outside of the jail, there are a range of capabilities, as well -as limitations. -The jail environment is, in effect, a subset of the host environment: -the jail file system appears as part of the host file system, and may -be directly modified by processes in the host environment. -Processes within the jail appear in the process listing of the host, -and may likewise be signalled or debugged. -The host process file system makes the hostname of the jail environment -accessible in /proc/procnum/status, allowing utilities in the host -environment to manage processes based on jailname. -However, the default configuration allows privileged processes within -jails to set the hostname of the jail, which makes the status file less -useful from a management perspective if the contents of the jail are -malicious. -To prevent a jail from changing its hostname, the -"jail.set_hostname_allowed" sysctl may be set to 0 prior to starting -any jails. -.PP -One aspect immediately observable in an environment with multiple jails -is that uids and gids are local to each jail environment: the uid associated -with a process in one jail may be for a different user than in another -jail. -This collision of identifiers is only visible in the host environment, -as normally processes from one jail are never visible in an environment -with another scope for user/uid and group/gid mapping. -Managers in the host environment should understand these scoping issues, -or confusion and unintended consequences may result. -.PP -Jailed processes are subject to the normal restrictions present for -any processes, including resource limits, and limits placed by the network -code, including firewall rules. -By specifying firewall rules for the IP address bound to a jail, it is -possible to place connectivity and bandwidth limitations on individual -jails, restricting services that may be consumed or offered. -.PP -Management of jails is an area that will see further improvement in -future versions of FreeBSD. Some of these potential improvements are -discussed later in this paper. diff --git a/share/doc/papers/jail/paper.ms b/share/doc/papers/jail/paper.ms deleted file mode 100644 index d47f664304a6..000000000000 --- a/share/doc/papers/jail/paper.ms +++ /dev/null @@ -1,437 +0,0 @@ -.\" -.\" $FreeBSD$ -.\" -.ds CH " -.nr PI 2n -.nr PS 12 -.nr LL 15c -.nr PO 3c -.nr FM 3.5c -.po 3c -.TL -Jails: Confining the omnipotent root. -.FS -This paper was presented at the 2nd International System Administration and Networking Conference "SANE 2000" May 22-25, 2000 in Maastricht, The Netherlands and is published in the in the proceedings. -.FE -.AU -Poul-Henning Kamp <phk@FreeBSD.org> -.AU -Robert N. M. Watson <rwatson@FreeBSD.org> -.AI -The FreeBSD Project -.FS -This work was sponsored by \fChttp://www.servetheweb.com/\fP and -donated to the FreeBSD Project for inclusion in the FreeBSD -OS. FreeBSD 4.0-RELEASE was the first release including this -code. -Follow-on work was sponsored by Safeport Network Services, -\fChttp://www.safeport.com/\fP -.FE -.AB -The traditional UNIX security model is simple but inexpressive. -Adding fine-grained access control improves the expressiveness, -but often dramatically increases both the cost of system management -and implementation complexity. -In environments with a more complex management model, with delegation -of some management functions to parties under varying degrees of trust, -the base UNIX model and most natural -extensions are inappropriate at best. -Where multiple mutually un-trusting parties are introduced, -``inappropriate'' rapidly transitions to ``nightmarish'', especially -with regards to data integrity and privacy protection. -.PP -The FreeBSD ``Jail'' facility provides the ability to partition -the operating system environment, while maintaining the simplicity -of the UNIX ``root'' model. -In Jail, users with privilege find that the scope of their requests -is limited to the jail, allowing system administrators to delegate -management capabilities for each virtual machine -environment. -Creating virtual machines in this manner has many potential uses; the -most popular thus far has been for providing virtual machine services -in Internet Service Provider environments. -.AE -.NH -Introduction -.PP -The UNIX access control mechanism is designed for an environment with two -types of users: those with, and without administrative privilege. -Within this framework, every attempt is made to provide an open -system, allowing easy sharing of files and inter-process communication. -As a member of the UNIX family, FreeBSD inherits these -security properties. -Users of FreeBSD in non-traditional UNIX environments must balance -their need for strong application support, high network performance -and functionality, and low total cost of ownership with the need -for alternative security models that are difficult or impossible to -implement with the UNIX security mechanisms. -.PP -One such consideration is the desire to delegate some (but not all) -administrative functions to untrusted or less trusted parties, and -simultaneously impose system-wide mandatory policies on process -interaction and sharing. -Attempting to create such an environment in the current-day FreeBSD -security environment is both difficult and costly: in many cases, -the burden of implementing these policies falls on user -applications, which means an increase in the size and complexity -of the code base, in turn translating to higher development -and maintenance cost, as well as less overall flexibility. -.PP -This abstract risk becomes more clear when applied to a practical, -real-world example: -many web service providers turn to the FreeBSD -operating system to host customer web sites, as it provides a -high-performance, network-centric server environment. -However, these providers have a number of concerns on their plate, both in -terms of protecting the integrity and confidentiality of their own -files and services from their customers, as well as protecting the files -and services of one customer from (accidental or -intentional) access by any other customer. -At the same time, a provider would like to provide -substantial autonomy to customers, allowing them to install and -maintain their own software, and to manage their own services, -such as web servers and other content-related daemon programs. -.PP -This problem space points strongly in the direction of a partitioning -solution, in which customer processes and storage are isolated from those of -other customers, both in terms of accidental disclosure of data or process -information, but also in terms of the ability to modify files or processes -outside of a compartment. -Delegation of management functions within the system must -be possible, but not at the cost of system-wide requirements, including -integrity and privacy protection between partitions. -.PP -However, UNIX-style access control makes it notoriously difficult to -compartmentalise functionality. -While mechanisms such as chroot(2) provide a modest -level compartmentalisation, it is well known -that these mechanisms have serious shortcomings, both in terms of the -scope of their functionality, and effectiveness at what they provide \s-2[CHROOT]\s+2. -.PP -In the case of the chroot(2) call, a process's visibility of -the file system name-space is limited to a single subtree. -However, the compartmentalisation does not extend to the process -or networking spaces and therefore both observation of and interference -with processes outside their compartment is possible. -.PP -To this end, we describe the new FreeBSD ``Jail'' facility, which -provides a strong partitioning solution, leveraging existing -mechanisms, such as chroot(2), to what effectively amounts to a -virtual machine environment. Processes in a jail are provided -full access to the files that they may manipulate, processes they -may influence, and network services they can make use of, and neither -access nor visibility of files, processes or network services outside -their partition. -.PP -Unlike other fine-grained security solutions, Jail does not -substantially increase the policy management requirements for the -system administrator, as each Jail is a virtual FreeBSD environment -permitting local policy to be independently managed, with much the -same properties as the main system itself, making Jail easy to use -for the administrator, and far more compatible with applications. -.NH -Traditional UNIX Security, or, ``God, root, what difference?" \s-2[UF]\s+2. -.PP -The traditional UNIX access model assigns numeric uids to each user of the -system. In turn, each process ``owned'' by a user will be tagged with that -user's uid in an unforgeable manner. The uids serve two purposes: first, -they determine how discretionary access control mechanisms will be applied, and -second, they are used to determine whether special privileges are accorded. -.PP -In the case of discretionary access controls, the primary object protected is -a file. The uid (and related gids indicating group membership) are mapped to -a set of rights for each object, courtesy the UNIX file mode, in effect acting -as a limited form of access control list. Jail is, in general, not concerned -with modifying the semantics of discretionary access control mechanisms, -although there are important implications from a management perspective. -.PP -For the purposes of determining whether special privileges are accorded to a -process, the check is simple: ``is the numeric uid equal to 0 ?''. -If so, the -process is acting with ``super-user privileges'', and all access checks are -granted, in effect allowing the process the ability to do whatever it wants -to \**. -.FS -\&... no matter how patently stupid it may be. -.FE -.PP -For the purposes of human convenience, uid 0 is canonically allocated -to the ``root'' user \s-2[ROOT]\s+2. -For the purposes of jail, this behaviour is extremely relevant: many of -these privileged operations can be used to manage system hardware and -configuration, file system name-space, and special network operations. -.PP -Many limitations to this model are immediately clear: the root user is a -single, concentrated source of privilege that is exposed to many pieces of -software, and as such an immediate target for attacks. In the event of a -compromise of the root capability set, the attacker has complete control over -the system. Even without an attacker, the risks of a single administrative -account are serious: delegating a narrow scope of capability to an -inexperienced administrator is difficult, as the granularity of delegation is -that of all system management abilities. These features make the omnipotent -root account a sharp, efficient and extremely dangerous tool. -.PP -The BSD family of operating systems have implemented the ``securelevel'' -mechanism which allows the administrator to block certain configuration -and management functions from being performed by root, -until the system is restarted and brought up into single-user mode. -While this does provide some amount of protection in the case of a root -compromise of the machine, it does nothing to address the need for -delegation of certain root abilities. -.NH -Other Solutions to the Root Problem -.PP -Many operating systems attempt to address these limitations by providing -fine-grained access controls for system resources \s-2[BIBA]\s+2. -These efforts vary in -degrees of success, but almost all suffer from at least three serious -limitations: -.PP -First, increasing the granularity of security controls increases the -complexity of the administration process, in turn increasing both the -opportunity for incorrect configuration, as well as the demand on -administrator time and resources. In many cases, the increased complexity -results in significant frustration for the administrator, which may result -in two -disastrous types of policy: ``all doors open as it's too much trouble'', and -``trust that the system is secure, when in fact it isn't''. -.PP -The extent of the trouble is best illustrated by the fact that an entire -niche industry has emerged providing tools to manage fine grained security -controls \s-2[UAS]\s+2. -.PP -Second, usefully segregating capabilities and assigning them to running code -and users is very difficult. Many privileged operations in UNIX seem -independent, but are in fact closely related, and the handing out of one -privilege may, in effect, be transitive to the many others. For example, in -some trusted operating systems, a system capability may be assigned to a -running process to allow it to read any file, for the purposes of backup. -However, this capability is, in effect, equivalent to the ability to switch to -any other account, as the ability to access any file provides access to system -keying material, which in turn provides the ability to authenticate as any -user. Similarly, many operating systems attempt to segregate management -capabilities from auditing capabilities. In a number of these operating -systems, however, ``management capabilities'' permit the administrator to -assign ``auditing capabilities'' to itself, or another account, circumventing -the segregation of capability. -.PP -Finally, introducing new security features often involves introducing new -security management APIs. When fine-grained capabilities are introduced to -replace the setuid mechanism in UNIX-like operating systems, applications that -previously did an ``appropriateness check'' to see if they were running as -root before executing must now be changed to know that they need not run as -root. In the case of applications running with privilege and executing other -programs, there is now a new set of privileges that must be voluntarily given -up before executing another program. These change can introduce significant -incompatibility for existing applications, and make life more difficult for -application developers who may not be aware of differing security semantics on -different systems \s-2[POSIX1e]\s+2. -.NH -The Jail Partitioning Solution -.PP -Jail neatly side-steps the majority of these problems through partitioning. -Rather -than introduce additional fine-grained access control mechanism, we partition -a FreeBSD environment (processes, file system, network resources) into a -management environment, and optionally subset Jail environments. In doing so, -we simultaneously maintain the existing UNIX security model, allowing -multiple users and a privileged root user in each jail, while -limiting the scope of root's activities to his jail. -Consequently the administrator of a -FreeBSD machine can partition the machine into separate jails, and provide -access to the super-user account in each of these without losing control of -the over-all environment. -.PP -A process in a partition is referred to as ``in jail''. When a FreeBSD -system is booted up after a fresh install, no processes will be in jail. -When -a process is placed in a jail, it, and any descendents of the process created -after the jail creation, will be in that jail. A process may be in only one -jail, and after creation, it can not leave the jail. -Jails are created when a -privileged process calls the jail(2) syscall, with a description of the jail as an -argument to the call. Each call to jail(2) creates a new jail; the only way -for a new process to enter the jail is by inheriting access to the jail from -another process already in that jail. -Processes may never -leave the jail they created, or were created in. -.KF -.PSPIC jail01.eps 4i -.ce 1 -Fig. 1 \(em Schematic diagram of machine with two configured jails -.sp -.KE -.PP -Membership in a jail involves a number of restrictions: access to the file -name-space is restricted in the style of chroot(2), the ability to bind network -resources is limited to a specific IP address, the ability to manipulate -system resources and perform privileged operations is sharply curtailed, and -the ability to interact with other processes is limited to only processes -inside the same jail. -.PP -Jail takes advantage of the existing chroot(2) behaviour to limit access to the -file system name-space for jailed processes. When a jail is created, it is -bound to a particular file system root. -Processes are unable to manipulate files that they cannot address, -and as such the integrity and confidentiality of files outside of the jail -file system root are protected. Traditional mechanisms for breaking out of -chroot(2) have been blocked. -In the expected and documented configuration, each jail is provided -with its exclusive file system root, and standard FreeBSD directory layout, -but this is not mandated by the implementation. -.PP -Each jail is bound to a single IP address: processes within the jail may not -make use of any other IP address for outgoing or incoming connections; this -includes the ability to restrict what network services a particular jail may -offer. As FreeBSD distinguishes attempts to bind all IP addresses from -attempts to bind a particular address, bind requests for all IP addresses are -redirected to the individual Jail address. Some network functionality -associated with privileged calls are wholesale disabled due to the nature of the -functionality offered, in particular facilities which would allow ``spoofing'' -of IP numbers or disruptive traffic to be generated have been disabled. -.PP -Processes running without root privileges will notice few, if any differences -between a jailed environment or un-jailed environment. Processes running with -root privileges will find that many restrictions apply to the privileged calls -they may make. Some calls will now return an access error \(em for example, an -attempt to create a device node will now fail. Others will have a more -limited scope than normal \(em attempts to bind a reserved port number on all -available addresses will result in binding only the address associated with -the jail. Other calls will succeed as normal: root may read a file owned by -any uid, as long as it is accessible through the jail file system name-space. -.PP -Processes within the jail will find that they are unable to interact or -even verify the existence of -processes outside the jail \(em processes within the jail are -prevented from delivering signals to processes outside the jail, as well as -connecting to those processes with debuggers, or even see them in the -sysctl or process file system monitoring mechanisms. Jail does not prevent, -nor is it intended to prevent, the use of covert channels or communications -mechanisms via accepted interfaces \(em for example, two processes may communicate -via sockets over the IP network interface. Nor does it attempt to provide -scheduling services based on the partition; however, it does prevent calls -that interfere with normal process operation. -.PP -As a result of these attempts to retain the standard FreeBSD API and -framework, almost all applications will run unaffected. Standard system -services such as Telnet, FTP, and SSH all behave normally, as do most third -party applications, including the popular Apache web server. -.NH -Jail Implementation -.PP -Processes running with root privileges in the jail find that there are serious -restrictions on what it is capable of doing \(em in particular, activities that -would extend outside of the jail: -.IP "" 5n -\(bu Modifying the running kernel by direct access and loading kernel -modules is prohibited. -.IP -\(bu Modifying any of the network configuration, interfaces, addresses, and -routing table is prohibited. -.IP -\(bu Mounting and unmounting file systems is prohibited. -.IP -\(bu Creating device nodes is prohibited. -.IP -\(bu Accessing raw, divert, or routing sockets is prohibited. -.IP -\(bu Modifying kernel runtime parameters, such as most sysctl settings, is -prohibited. -.IP -\(bu Changing securelevel-related file flags is prohibited. -.IP -\(bu Accessing network resources not associated with the jail is prohibited. -.bp -.PP -Other privileged activities are permitted as long as they are limited to the -scope of the jail: -.IP "" 5n -\(bu Signalling any process within the jail is permitted. -.IP -\(bu Changing the ownership and mode of any file within the jail is permitted, as -long as the file flags permit this. -.IP -\(bu Deleting any file within the jail is permitted, as long as the file flags -permit this. -.IP -\(bu Binding reserved TCP and UDP port numbers on the jails IP address is -permitted. (Attempts to bind TCP and UDP ports using INADDR_ANY will be -redirected to the jails IP address.) -.IP -\(bu Functions which operate on the uid/gid space are all permitted since they -act as labels for filesystem objects of proceses -which are partitioned off by other mechanisms. -.PP -These restrictions on root access limit the scope of root processes, enabling -most applications to run un-hindered, but preventing calls that might allow an -application to reach beyond the jail and influence other processes or -system-wide configuration. -.PP -.so implementation.ms -.so mgt.ms -.so future.ms -.NH -Conclusion -.PP -The jail facility provides FreeBSD with a conceptually simple security -partitioning mechanism, allowing the delegation of administrative rights -within virtual machine partitions. -.PP -The implementation relies on -restricting access within the jail environment to a well-defined subset -of the overall host environment. This includes limiting interaction -between processes, and to files, network resources, and privileged -operations. Administrative overhead is reduced through avoiding -fine-grained access control mechanisms, and maintaining a consistent -administrative interface across partitions and the host environment. -.PP -The jail facility has already seen widespread deployment in particular as -a vehicle for delivering "virtual private server" services. -.PP -The jail code is included in the base system as part of FreeBSD 4.0-RELEASE, -and fully documented in the jail(2) and jail(8) man-pages. -.bp -.SH -Notes & References -.IP \s-2[BIBA]\s+2 .5i -K. J. Biba, Integrity Considerations for Secure -Computer Systems, USAF Electronic Systems Division, 1977 -.IP \s-2[CHROOT]\s+2 .5i -Dr. Marshall Kirk Mckusick, private communication: -``According to the SCCS logs, the chroot call was added by Bill Joy -on March 18, 1982 approximately 1.5 years before 4.2BSD was released. -That was well before we had ftp servers of any sort (ftp did not -show up in the source tree until January 1983). My best guess as -to its purpose was to allow Bill to chroot into the /4.2BSD build -directory and build a system using only the files, include files, -etc contained in that tree. That was the only use of chroot that -I remember from the early days.'' -.IP \s-2[LOTTERY1]\s+2 .5i -David Petrou and John Milford. Proportional-Share Scheduling: -Implementation and Evaluation in a Widely-Deployed Operating System, -December 1997. -.nf -\s-2\fChttp://www.cs.cmu.edu/~dpetrou/papers/freebsd_lottery_writeup98.ps\fP\s+2 -\s-2\fChttp://www.cs.cmu.edu/~dpetrou/code/freebsd_lottery_code.tar.gz\fP\s+2 -.IP \s-2[LOTTERY2]\s+2 .5i -Carl A. Waldspurger and William E. Weihl. Lottery Scheduling: Flexible Proportional-Share Resource Management, Proceedings of the First Symposium on Operating Systems Design and Implementation (OSDI '94), pages 1-11, Monterey, California, November 1994. -.nf -\s-2\fChttp://www.research.digital.com/SRC/personal/caw/papers.html\fP\s+2 -.IP \s-2[POSIX1e]\s+2 .5i -Draft Standard for Information Technology \(em -Portable Operating System Interface (POSIX) \(em -Part 1: System Application Program Interface (API) \(em Amendment: -Protection, Audit and Control Interfaces [C Language] -IEEE Std 1003.1e Draft 17 Editor Casey Schaufler -.IP \s-2[ROOT]\s+2 .5i -Historically other names have been used at times, Zilog for instance -called the super-user account ``zeus''. -.IP \s-2[UAS]\s+2 .5i -One such niche product is the ``UAS'' system to maintain and audit -RACF configurations on MVS systems. -.nf -\s-2\fChttp://www.entactinfo.com/products/uas/\fP\s+2 -.IP \s-2[UF]\s+2 .5i -Quote from the User-Friendly cartoon by Illiad. -.nf -\s-2\fChttp://www.userfriendly.org/cartoons/archives/98nov/19981111.html\fP\s+2 diff --git a/share/examples/kld/dyn_sysctl/Makefile b/share/examples/kld/dyn_sysctl/Makefile deleted file mode 100644 index 3c63a8a5f6ad..000000000000 --- a/share/examples/kld/dyn_sysctl/Makefile +++ /dev/null @@ -1,18 +0,0 @@ -# $FreeBSD$ - -SRCS = dyn_sysctl.c -CFLAGS = -I/sys -KMOD = dyn_sysctl -KO = ${KMOD}.ko -KLDMOD = t - -KLDLOAD = /sbin/kldload -KLDUNLOAD = /sbin/kldunload - -load: ${KO} - ${KLDLOAD} -v ./${KO} - -unload: ${KO} - ${KLDUNLOAD} -v -n ${KO} - -.include <bsd.kmod.mk> diff --git a/share/examples/kld/dyn_sysctl/README b/share/examples/kld/dyn_sysctl/README deleted file mode 100644 index 4dfa3c6bdfbd..000000000000 --- a/share/examples/kld/dyn_sysctl/README +++ /dev/null @@ -1,8 +0,0 @@ -This example module creates partially overlapping subtrees to demonstrate -reference counting. It also contains example of attaching a subtree to the -wrong place, i.e. to a dynamic oid that could belong to someone else. -The framework should deal with this case gracefully. - -Andrzej Bialecki <abial@freebsd.org> - -$FreeBSD$ diff --git a/share/examples/kld/dyn_sysctl/dyn_sysctl.c b/share/examples/kld/dyn_sysctl/dyn_sysctl.c deleted file mode 100644 index e066b56be316..000000000000 --- a/share/examples/kld/dyn_sysctl/dyn_sysctl.c +++ /dev/null @@ -1,168 +0,0 @@ -/*- - * Copyright (c) 2000 Andrzej Bialecki <abial@freebsd.org> - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - * - * $FreeBSD$ - */ - -#include <sys/types.h> -#include <sys/param.h> -#include <sys/systm.h> -#include <sys/module.h> -#include <sys/sysctl.h> -#include <sys/kernel.h> - - -/* Some example data */ -static long a = 100; -static int b = 200; -static char *c = "hi there from dyn_sysctl"; -static struct sysctl_oid *a_root, *a_root1, *b_root; -static struct sysctl_ctx_list clist, clist1, clist2; - -static int -sysctl_dyn_sysctl_test (SYSCTL_HANDLER_ARGS) -{ - char *buf = "let's produce some text..."; - - return (sysctl_handle_string(oidp, buf, strlen(buf), req)); -} - -/* - * The function called at load/unload. - */ -static int -load (module_t mod, int cmd, void *arg) -{ - int error; - - error = 0; - switch (cmd) { - case MOD_LOAD : - /* Initialize the contexts */ - printf("Initializing contexts and creating subtrees.\n\n"); - sysctl_ctx_init(&clist); - sysctl_ctx_init(&clist1); - sysctl_ctx_init(&clist2); - /* - * Create two partially overlapping subtrees, belonging - * to different contexts. - */ - printf("TREE ROOT NAME\n"); - a_root = SYSCTL_ADD_NODE(&clist, - SYSCTL_STATIC_CHILDREN(/* top of sysctl tree */), - OID_AUTO, dyn_sysctl, CTLFLAG_RW, 0, - "dyn_sysctl root node"); - a_root = SYSCTL_ADD_NODE(&clist1, - SYSCTL_STATIC_CHILDREN(/* top of sysctl tree */), - OID_AUTO, dyn_sysctl, CTLFLAG_RW, 0, - "dyn_sysctl root node"); - if(a_root == NULL) { - printf("SYSCTL_ADD_NODE failed!\n"); - return (EINVAL); - } - SYSCTL_ADD_LONG(&clist, SYSCTL_CHILDREN(a_root), - OID_AUTO, long_a, CTLFLAG_RW, &a, "just to try"); - SYSCTL_ADD_INT(&clist, SYSCTL_CHILDREN(a_root), - OID_AUTO, int_b, CTLFLAG_RW, &b, 0, "just to try 1"); - a_root1=SYSCTL_ADD_NODE(&clist, SYSCTL_CHILDREN(a_root), - OID_AUTO, nextlevel, CTLFLAG_RD, 0, "one level down"); - SYSCTL_ADD_STRING(&clist, SYSCTL_CHILDREN(a_root1), - OID_AUTO, string_c, CTLFLAG_RD, c, 0, "just to try 2"); - printf("1. (%p) / dyn_sysctl\n", &clist); - - /* Add a subtree under already existing category */ - a_root1 = SYSCTL_ADD_NODE(&clist, SYSCTL_STATIC_CHILDREN(_kern), - OID_AUTO, dyn_sysctl, CTLFLAG_RW, 0, "dyn_sysctl root node"); - if(a_root1 == NULL) { - printf("SYSCTL_ADD_NODE failed!\n"); - return (EINVAL); - } - SYSCTL_ADD_PROC(&clist, SYSCTL_CHILDREN(a_root1), - OID_AUTO, procedure, CTLFLAG_RD, 0, 0, - sysctl_dyn_sysctl_test, "A", "I can be here, too"); - printf(" (%p) /kern dyn_sysctl\n", &clist); - - /* Overlap second tree with the first. */ - b_root = SYSCTL_ADD_NODE(&clist1, SYSCTL_CHILDREN(a_root), - OID_AUTO, nextlevel, CTLFLAG_RD, 0, "one level down"); - SYSCTL_ADD_STRING(&clist1, SYSCTL_CHILDREN(b_root), - OID_AUTO, string_c1, CTLFLAG_RD, c, 0, "just to try 2"); - printf("2. (%p) / dyn_sysctl (overlapping #1)\n", &clist1); - - /* - * And now do something stupid. Connect another subtree to - * dynamic oid. - * WARNING: this is an example of WRONG use of dynamic sysctls. - */ - b_root=SYSCTL_ADD_NODE(&clist2, SYSCTL_CHILDREN(a_root1), - OID_AUTO, bad, CTLFLAG_RW, 0, "dependent node"); - SYSCTL_ADD_STRING(&clist2, SYSCTL_CHILDREN(b_root), - OID_AUTO, string_c, CTLFLAG_RD, c, 0, "shouldn't panic"); - printf("3. (%p) /kern/dyn_sysctl bad (WRONG!)\n", &clist2); - break; - case MOD_UNLOAD : - printf("1. Try to free ctx1 (%p): ", &clist); - if(sysctl_ctx_free(&clist)) - printf("failed: expected. Need to remove ctx3 first.\n"); - else - printf("HELP! sysctl_ctx_free(%p) succeeded. EXPECT PANIC!!!\n", &clist); - printf("2. Try to free ctx3 (%p): ", &clist2); - if(sysctl_ctx_free(&clist2)) { - printf("sysctl_ctx_free(%p) failed!\n", &clist2); - /* Remove subtree forcefully... */ - sysctl_remove_oid(b_root, 1, 1); - printf("sysctl_remove_oid(%p) succeeded\n", b_root); - } else - printf("Ok\n"); - printf("3. Try to free ctx1 (%p) again: ", &clist); - if(sysctl_ctx_free(&clist)) { - printf("sysctl_ctx_free(%p) failed!\n", &clist); - /* Remove subtree forcefully... */ - sysctl_remove_oid(a_root1, 1, 1); - printf("sysctl_remove_oid(%p) succeeded\n", a_root1); - } else - printf("Ok\n"); - printf("4. Try to free ctx2 (%p): ", &clist1); - if(sysctl_ctx_free(&clist1)) { - printf("sysctl_ctx_free(%p) failed!\n", &clist1); - /* Remove subtree forcefully... */ - sysctl_remove_oid(a_root, 1, 1); - } else - printf("Ok\n"); - break; - default : - error = EINVAL; - break; - } - return error; -} - -static moduledata_t mod_data= { - "dyn_sysctl", - load, - 0 -}; - -DECLARE_MODULE(dyn_sysctl, mod_data, SI_SUB_EXEC, SI_ORDER_ANY); diff --git a/share/man/man4/tap.4 b/share/man/man4/tap.4 deleted file mode 100644 index fba5466cd0bd..000000000000 --- a/share/man/man4/tap.4 +++ /dev/null @@ -1,217 +0,0 @@ -.\" $FreeBSD$ -.\" Based on PR#2411 -.\" -.Dd July 9, 2000 -.Os -.Dt TAP 4 -.Sh NAME -.Nm tap -.Nd Ethernet tunnel software network interface -.Sh SYNOPSIS -.Cd pseudo-device tap -.Sh DESCRIPTION -The -.Nm tap -interface is a software loopback mechanism that can be loosely -described as the network interface analog of the -.Xr pty 4 , -that is, -.Nm tap -does for network interfaces what the -.Nm pty -driver does for terminals. -.Pp -The -.Nm tap -driver, like the -.Nm pty -driver, provides two interfaces: an interface like the usual facility -it is simulating -.Po -an Ethernet network interface in the case of -.Nm tap , -or a terminal for -.Nm pty -.Pc , -and a character-special device -.Dq control -interface. -.Pp -The network interfaces are named -.Sy tap Ns Ar 0 , -.Sy tap Ns Ar 1 , -etc, as many as were made by -.Xr MAKEDEV 8 . -Each one supports the usual Ethernet network-interface -.Xr ioctl 2 Ns s , -such as -.Dv SIOCSIFADDR -and -.Dv SIOCSIFNETMASK , -and thus can be used with -.Xr ifconfig 8 -like any other Ethernet interface. When the system chooses to transmit -an Ethernet frame on the network interface, the frame can be read from -the control device -.Po -it appears as -.Dq input -there -.Pc ; -writing an Ethernet frame to the control device generates an input frame on -the network interface, as if the -.Pq non-existent -hardware had just received it. -.Pp -The Ethernet tunnel device, normally -.Pa /dev/tap Ns Sy N , -is exclusive-open -.Po -it cannot be opened if it is already open -.Pc -and is restricted to the super-user. -A -.Fn read -call will return an error -.Pq Er EHOSTDOWN -if the interface is not -.Dq ready . -Once the interface is ready, -.Fn read -will return an Ethernet frame if one is available; if not, it will -either block until one is or return -.Er EWOULDBLOCK , -depending on whether non-blocking I/O has been enabled. If the frame -is longer than is allowed for in the buffer passed to -.Fn read , -the extra data will be silently dropped. -.Pp -A -.Xr write 2 -call passes an Ethernet frame in to be -.Dq received -on the pseudo-interface. Each -.Fn write -call supplies exactly one frame; the frame length is taken from the -amount of data provided to -.Fn write . -Writes will not block; if the frame cannot be accepted -for a transient reason -.Pq e.g., no buffer space available , -it is silently dropped; if the reason is not transient -.Pq e.g., frame too large , -an error is returned. -The following -.Xr ioctl 2 -calls are supported -.Pq defined in Aq Pa net/if_tap.h Ns : -.Bl -tag -width VMIO_SIOCSETMACADDR -.It Dv TAPSDEBUG -The argument should be a pointer to an -.Va int ; -this sets the internal debugging variable to that value. What, if -anything, this variable controls is not documented here; see the source -code. -.It Dv TAPGDEBUG -The argument should be a pointer to an -.Va int ; -this stores the internal debugging variable's value into it. -.It Dv FIONBIO -Turn non-blocking I/O for reads off or on, according as the argument -.Va int Ns 's -value is or isn't zero -.Pq Writes are always nonblocking . -.It Dv FIOASYNC -Turn asynchronous I/O for reads -.Po -i.e., generation of -.Dv SIGIO -when data is available to be read -.Pc -off or on, according as the argument -.Va int Ns 's -value is or isn't zero. -.It Dv FIONREAD -If any frames are queued to be read, store the size of the first one into the argument -.Va int ; -otherwise, store zero. -.It Dv TIOCSPGRP -Set the process group to receive -.Dv SIGIO -signals, when asynchronous I/O is enabled, to the argument -.Va int -value. -.It Dv TIOCGPGRP -Retrieve the process group value for -.Dv SIGIO -signals into the argument -.Va int -value. -.It SIOCGIFADDR -Retrieve the Media Access Control -.Pq MAC -address. This command should be executed on descriptor, associated with -control device -.Pq Pa /dev/tap Ns Sy N . -The -.Va buffer , -which is passed as argument, is expected to have enought space to store -.Pq MAC -address. -.It SIOCSIFADDR -Set the Media Access Control -.Pq MAC -address. This command should be executed on a descriptor, associated with -control device -.Pq Pa /dev/tap Ns Sy N . -.El -.Pp -The control device also supports -.Xr select 2 -for read; selecting for write is pointless, and always succeeds, since -writes are always non-blocking. -.Pp -On the last close of the data device, by default, the interface is -brought down -.Po -as if with -.Dq ifconfig tap Ns Sy N No down -.Pc . -All queued frames are thrown away. If the interface is up when the data -device is not open output frames are always thrown away rather than -letting them pile up. -.Pp -The -.Nm tap -device is also can be used with VMware port as a replacement -of VMnet device driver. The driver uses minor number to select between -.Nm tap -and -.Nm vmnet -devices. VMnet minor numbering is -.Va 0x10000 -+ -.Va N . -Where -.Va N -is a VMnet unit number. In this case control device is expected to be -.Pa /dev/vmnet Ns Sy N , -and network interface will be -.Sy vmnet Ns Ar N . -Everything else is the same. -.Pp -In addition to mentioned above -.Xr ioctl 2 -there are additional one for VMware port. -.Bl -tag -width VMIO_SIOCSETMACADDR -.It VMIO_SIOCSIFFLAGS -VMware -.Dv SIOCSIFFLAGS . -.El -.Sh SEE ALSO -.Xr inet 4 , -.Xr intro 4 -.\" .Sh BUGS -.Sh AUTHORS -This man page has been obtained from -.Bx Free . diff --git a/share/man/man5/periodic.conf.5 b/share/man/man5/periodic.conf.5 deleted file mode 100644 index 3acce7892e1d..000000000000 --- a/share/man/man5/periodic.conf.5 +++ /dev/null @@ -1,443 +0,0 @@ -.\"- -.\" Copyright (c) 2000 Brian Somers <brian@Awfulhak.org> -.\" All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" $FreeBSD$ -.\" -.Dd June 22, 2000 -.Dt PERIODIC.CONF 5 -.Os FreeBSD 5.0 -.Sh NAME -.Nm periodic.conf -.Nd periodic job configuration information. -.Sh DESCRIPTION -The file -.Nm periodic.conf -contains a description of how daily, weekly and montly system maintenance -jobs should run. -It resides in the -.Pa /etc/defaults -directory and parts may be overridden by a file of the same name in -.Pa /etc , -which itself may be overridden by the -.Pa /etc/periodic.conf.local -file. -.Pp -.Nm -is actually sourced as a shell script from each of the periodic scripts -and is intended to simply provide default configuration variables. -.Pp -The following list provides a name and short description for each -variable you can set in the -.Nm -file. -.Bl -tag -offset 4n -width 2n -.It Ar local_periodic -(str) List of directories to search for periodic scripts. -.El -.B Daily variables -.Pp -The following variables are used by the standard scripts that reside in -.Pa /etc/periodic/daily : -.Bl -tag -offset 4n -width 2n -.It Ar daily_clean_disks_enable -(bool) Set to -.Dq YES -if you want to remove all files matching -.Ar daily_clean_disks_files -daily. -.It Ar daily_clean_disks_files -(str) Set to a list of file names to match. -Wild cards are permitted. -.It Ar daily_clean_disks_days -(int) When -.Ar daily_clean_disks_enable -is set to -.Dq YES , -this must also be set to the number of days old that a file's access -and modification times must be before it's deleted. -.It Ar daily_clean_disks_verbose -(bool) Set to -.Dq YES -if you want the removed files to be reported in your daily output. -.It Ar daily_clean_tmps_enable -(bool) Set to -.Dq YES -if you want to clear temporary directories daily. -.It Ar daily_clean_tmps_dirs -(str) Set to the list of directories to clear if -.Ar daily_clean_tmps_enable -is set to -.Dq YES . -.It Ar daily_clean_tmps_days -(int) When -.Ar daily_clean_tmps_enable -is set, this must also be set to the number of days old that a file's access -and modification times must be before it's deleted. -.It Ar daily_clean_tmps_ignore -(str) Set to the list of files that should not be deleted when -.Ar daily_clean_tmps_enable -is set to -.Dq YES . -Wild card characters are permitted. -.It Ar daily_clean_tmps_verbose -(bool) Set to -.Dq YES -if you want the removed files to be reported in your daily output. -.It Ar daily_clean_preserve_enable -(bool) Set to -.Dq YES -if you wish to remove old files from -.Pa /var/preserve . -.It Ar daily_clean_preserve_days -(num) Set to the number of days that files must not have been modified before -they are deleted. -.It Ar daily_clean_preserve_verbose -(bool) Set to -.Dq YES -if you want the removed files to be reported in your daily output. -.It Ar daily_clean_msgs_enable -(bool) Set to -.Dq YES -if you old system messages to be purged. -.It Ar daily_clean_msgs_days -(num) Set to the number of days that files must not have been modified before -they are deleted. -If this variable is left blank, the -.Xr msgs 1 -default is used. -.It Ar daily_clean_rwho_enable -(bool) Set to -.Dq YES -if you wish old files in -.Pa /var/who -to be purged. -.It Ar daily_clean_rwho_days -(num) Set to the number of days that files must not have been modified before -they are deleted. -.It Ar daily_clean_rwho_verbose -(bool) Set to -.Dq YES -if you want the removed files to be reported in your daily output. -.It Ar daily_clean_hoststat_enable -(bool) Set to -.Dq YES -if you wish old files in -.Pa /var/spool/.hoststat -to be purged. -.It Ar daily_clean_hoststat_days -(num) Set to the number of days that files must not have been modified before -they are deleted. -.It Ar daily_clean_hoststat_verbose -(bool) Set to -.Dq YES -if you want the removed files to be reported in your daily output. -.It Ar daily_backup_passwd_enable -(bool) Set to -.Dq YES -if you want the -.Pa /etc/master.passwd -and -.Pa /etc/group -files backed up and reported on. -Reporting consists of checking both files for modifications and running -.Xr chkgrp 8 -on the -.Pa group -file. -.It Ar daily_backup_aliases_enable -(bool) Set to -.Dq YES -if you want the -.Pa /etc/aliases -file backed up and modifications to be displayed in your daily output. -.It Ar daily_backup_distfile_enable -(bool) Set to -.Dq YES -if you want the -.Pa /etc/Distfile -file backed up and modifications to be displayed in your daily output. -.It Ar daily_calendar_enable -(bool) Set to -.Dq YES -if you want to run -.Ic calendar -a -daily. -.It Ar daily_accounting_enable -(bool) Set to -.Dq YES -if you want to rotate your daily accounting files. -No rotations are necessary unless -.Ar accounting_enable -is enabled in -.Xr rc.conf 5 . -.It Ar daily_accounting_compress -(bool) Set to -.Dq YES -if you want your daily accounting files to be compressed using -.Xr gzip 1 . -.It Ar daily_distfile_enable -(bool) Set to -.Dq YES -if you want to run -.Xr rdist 1 -daily. -The -.Pa /etc/Distfile -file must also exist. -.It Pa daily_news_expire_enable -(bool) Set to -.Dq YES -if you want to run -.Pa /etc/news.expire . -.It Pa daily_uuclean_enable -(bool) Set to -.Dq YES -if you want to run -.Pa /etc/uuclean.daily . -.It Ar daily_status_disks_enable -(bool) Set to -.Dq YES -if you want to run -.Xr df 1 -.Po -with the arguments supplied in -.Ar daily_status_disks_df_flags -.Pc -and -.Ic dump W . -.It Ar daily_status_disks_df_flags -(str) Set to the arguments for the -.Xr df 1 -utility when -.Ar daily_status_disks_enable -is set to -.Dq YES . -.It Ar daily_status_uucp_enable -(bool) Set to -.Dq YES -if you want to run -.Pa /etc/uuclean.daily . -.It Ar daily_status_network_enable -(bool) Set to -.Dq YES -if you want to run -.Ic netstat -i . -.It Ar daily_status_network_usedns -(bool) Set to -.Dq YES -if you want to run -.Xr netstat 1 -without the -.Fl n -option (to do DNS lookups). -.It Ar daily_status_rwho_enable -(bool) Set to -.Dq YES -if you want to run -.Xr uptime 1 -(or -.Xr ruptime 1 -if -.Ar rwhod_enable -is set to -.Dq YES -in -.Pa /etc/rc.conf ). -.It Ar daily_status_mailq_enable -(bool) Set to -.Dq YES -if you want to run -.Xr mailq 1 . -.It Ar daily_status_mailq_shorten -(bool) Set to -.Dq YES -if you want to shorten the -.Nm mailq -output when -.Ar daily_status_mailq_enable -is set to -.Dq YES . -.It Ar daily_status_security_enable -(bool) Set to -.Dq YES -if you want to run -.Pa /etc/security . -.It Ar daily_status_security_inline -(bool) Set to -.Dq YES -if you want to run -.Pa /etc/security -inline. -The alternative is to run it as a background job, mailing the output to -.An root . -.It Ar daily_status_security_noamd -(bool) Set to -.Dq YES -if you want to ignore -.Xr amd 8 -mounts when comparing against yesterdays filesystem mounts. -.It Ar daily_status_security_nomfs -(bool) Set to -.Dq YES -if you want to ignore -.Xr mfs 8 -mounts when comparing against yesterdays filesystem mounts. -.It Ar daily_status_mail_rejects_enable -(bool) Set to -.Dq YES -if you want to summarise mail rejections logged to -.Pa /var/log/maillog -for the previous day. -.It Ar daily_status_mail_rejects_logs -(num) Set to the number of maillog files that should be checked -for yesterday's mail rejects. -.It Ar daily_local -(str) Set to a list of extra scripts that should be run after all other -daily scripts. -All scripts must be absolute path names. -.El -.Pp -The following variables are used by the standard scripts that reside in -.Pa /etc/periodic/weekly : -.Bl -tag -offset 4n -width 2n -.It Ar weekly_clean_kvmdb_enable -(bool) Set to -.Dq YES -if you want to purge old -.Pa /var/db/kvm_*.db -files. -The kvm file for the current kernel will not be purged. -.It Ar weekly_clean_kvmdb_days -(num) Set to the number of days that the file must not have been accessed -before being deleted. -.It Ar weekly_clean_kvmdb_verbose -(bool) Set to -.Dq YES -if you want the removed files to be reported in your daily output. -.It Ar weekly_uucp_enable -(bool) Set to -.Dq YES -if you want to run -.Pa /usr/libexec/uucp/clean.weekly . -.It Ar weekly_locate_enable -(bool) Set to -.Dq YES -if you want to run -.Pa /usr/libexec/locate.updatedb . -This script is run using -.Ic nice -5 -as user -.An nobody , -and generates the table used by the -.Xr locate 1 -command. -.It Ar weekly_whatis_enable -(bool) Set to -.Dq YES -if you want to run -.Pa /usr/libexec/makewhatis.local . -This script regenerates the database used by the -.Xr apropos 1 -command. -.It Ar weekly_catman_enable -(bool) Set to -.Dq YES -if you want to run -.Pa /usr/libexec/catman.local . -This script processes all out of date man pages, speeding up the -.Xr man 1 -command at the expense of disk space. -.It Ar weekly_noid_enable -(bool) Set to -.Dq YES -if you want to locate orphaned files on the system. -An orphaned file is one with an invalid owner or group. -.It Ar weekly_noid_dirs -(str) A list of directories under which orphaned files are searched for. -This would usually be set to -.Pa / . -.It Ar weekly_status_pkg_dirs -(bool) Set to -.Dq YES -if you want to use -.Xr pkg_version 1 -to list installed packages which are out of date. -.It Ar weekly_local -(str) Set to a list of extra scripts that should be run after all other -weekly scripts. -All scripts must be absolute path names. -.El -.Pp -The following variables are used by the standard scripts that reside in -.Pa /etc/periodic/monthly : -.Bl -tag -offset 4n -width 2n -.It Ar monthly_accounting_enable -(bool) Set to -.Dq YES -if you want to do login accounting using the -.Xr ac 8 -command. -.It Ar monthly_local -(str) Set to a list of extra scripts that should be run after all other -monthly scripts. -All scripts must be absolute path names. -.El -.Sh FILES -.Bl -tag -width /etc/defaults/periodic.conf -.It Pa /etc/defaults/periodic.conf -The default configuration file. -This file contains all default variables and values. -.It Pa /etc/periodic.conf -The usual system specific variable override file. -.It Pa /etc/periodic.conf.local -An additional override file, useful when -.Pa /etc/periodic.conf -is shared or distributed. -.El -.Sh SEE ALSO -.Xr apropos 1 , -.Xr calendar 1 , -.Xr df 1 , -.Xr gzip 1 , -.Xr locate 1 , -.Xr man 1 , -.Xr msgs 1 , -.Xr netstat 1 , -.Xr nice 1 , -.Xr pkg_version 1 , -.Xr rdist 1 , -.Xr rc.conf 5 , -.Xr ac 8 , -.Xr chkgrp 8 , -.Xr dump 8 , -.Xr mfs 8 . -.Xr periodic 8 . -.Sh HISTORY -The -.Nm -file appeared in -.Fx 5.0 . -.Sh AUTHORS -.An Brian Somers Aq brian@Awfulhak.org . diff --git a/share/man/man9/accept_filter.9 b/share/man/man9/accept_filter.9 deleted file mode 100644 index 94a113cc3886..000000000000 --- a/share/man/man9/accept_filter.9 +++ /dev/null @@ -1,134 +0,0 @@ -.\" -.\" Copyright (c) 2000 Alfred Perlstein -.\" -.\" All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR -.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. -.\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT, -.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT -.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF -.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -.\" -.\" $FreeBSD$ -.\" " -.Dd June 25, 2000 -.Os -.Dt ACCEPT_FILTER 9 -.Sh NAME -.Nm accept_filter , -.Nm accept_filt_add , -.Nm accept_filt_del , -.Nm accept_filt_generic_mod_event , -.Nm accept_filt_get -.Nd filter incoming connections -.Sh SYNOPSIS -.Fd #include <sys/types.h> -.Fd #include <sys/socket.h> -.Fd #include <sys/socketvar.h> -.Ft int -.Fn accept_filt_add "struct accept_filter *filt" -.Ft int -.Fn accept_filt_del "char *name" -.Ft int -.Fn accept_filt_generic_mod_event "module_t mod" "int event" "void *data" -.Ft struct accept_filter * -.Fn accept_filt_get "char *name" -.Sh DESCRIPTION -Accept filters allow an application to request -that the kernel pre-process incoming connections. -An accept filter is requested via the -.Xr setsockopt 2 -system call, passing in an -.Fa optname -of -.Dv SO_ACCEPTFILTER . -.Sh IMPLEMENTATION NOTES -A module that wants to be an accept filter -must provide a struct accept_filter to the system: -.Bd -literal -struct accept_filter { - char accf_name[16]; - void (*accf_callback) - __P((struct socket *so, void *arg, int waitflag)); - void * (*accf_create) - __P((struct socket *so, char *arg)); - void (*accf_destroy) - __P((struct socket *so)); - SLIST_ENTRY(accept_filter) accf_next; /* next on the list */ -}; -.Ed -.Pp -The module should register it with the function -.Fn accept_filt_add , -passing a pointer to a struct accept_filter, allocated with -.Xr MALLOC 9 -.Pp -The fields of -.Fa struct accept_filter -are as follows: -.Bl -tag -width accf_callbackXXX -.It accf_name -Name of the filter; -this is how it will be accessed from userland. -.It accf_callback -The callback that the kernel will do -once the connection is established. -It is the same as a socket upcall -and will be called when the connection is established -and whenever new data arrives on the socket, -unless the callback modifies the socket's flags. -.It accf_create -Called whenever a -.Xr setsockopt 2 -installs the filter onto -a listening socket. -.It accf_destroy -Called whenever the user removes the accept filter on the socket. -.El -.Pp -.Fn accept_filt_del -passed the same string used in accept_filter.accf_name during registration -with -.Fn accept_filt_add , -the kernel will then disallow and further userland use of the filter. -.Pp -.Fn accept_filt_get -is used internally to locate which accept filter to use via the -.Fn setsocketopt -syscall. -.Pp -.Fn accept_filt_generic_mod_event -provides a simple way to avoid duplicate -code for accept filters which don't use -argument field to load and unload -themselves. It is a function that can be -put in the load/unload struct -for the -.Fn DECLARE_MODULE -macro. -.Sh SEE ALSO -.Xr setsockopt 2 , -.Xr malloc 9 -.Sh HISTORY -The accept filter mechanism was introduced in -.Fx 4.0 . -.Sh AUTHORS -This manual page has been written by -.An Alfred Perlstein , -Sheldon Hearn and Jeroen Ruigrok van der Werven. -The accept filter concept was pioneered by engineers at Yahoo.com -and refined to be a loadable module system by Alfred Perlstein. diff --git a/share/man/man9/sysctl_add_oid.9 b/share/man/man9/sysctl_add_oid.9 deleted file mode 100644 index 3d5769b9b4c0..000000000000 --- a/share/man/man9/sysctl_add_oid.9 +++ /dev/null @@ -1,502 +0,0 @@ -.\" -.\" Copyright (c) 2000, Andrzej Bialecki <abial@freebsd.org> -.\" All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. The name of the author may not be used to endorse or promote products -.\" derived from this software without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" $FreeBSD$ -.\" -.Dd Jul 15, 2000 -.Dt SYSCTL_ADD_OID 9 -.Os -.Sh NAME -.Nm sysctl_add_oid , -.Nm sysctl_remove_oid -.Nd runtime sysctl tree manipulation -.Sh SYNOPSIS -.Fd #include <sys/sysctl.h> -.Ft struct sysctl_oid * -.Fo sysctl_add_oid -.Fa "struct sysctl_ctx_list *ctx" -.Fa "struct sysctl_oid_list *parent" -.Fa "int number" -.Fa "char *name" -.Fa "int kind" -.Fa "void *arg1" -.Fa "int arg2" -.Fa "int (*handler) (SYSCTL_HANDLER_ARGS)" -.Fa "char *format" -.Fa "char *descr" -.Fc -.Ft int -.Fo sysctl_remove_oid -.Fa "struct sysctl_oid *oidp" -.Fa "int del" -.Fa "int recurse" -.Fc -.Ft struct sysctl_oid_list * -.Fo SYSCTL_CHILDREN -.Fa "struct sysctl_oid *oidp" -.Fc -.Ft struct sysctl_oid_list * -.Fo SYSCTL_STATIC_CHILDREN -.Fa "OID_NAME" -.Fc -.Ft struct sysctl_oid * -.Fo SYSCTL_ADD_OID -.Fa "struct sysctl_ctx_list *ctx" -.Fa "struct sysctl_oid_list *parent" -.Fa "int number" -.Fa "NAME" -.Fa "int kind" -.Fa "void *arg1" -.Fa "int arg2" -.Fa "int (*handler) (SYSCTL_HANDLER_ARGS)" -.Fa "char *format" -.Fa "char *descr" -.Fc -.Ft struct sysctl_oid * -.Fo SYSCTL_ADD_NODE -.Fa "struct sysctl_ctx_list *ctx" -.Fa "struct sysctl_oid_list *parent" -.Fa "int number" -.Fa "NAME" -.Fa "int access" -.Fa "int (*handler) (SYSCTL_HANDLER_ARGS)" -.Fa "char *descr" -.Fc -.Ft struct sysctl_oid * -.Fo SYSCTL_ADD_STRING -.Fa "struct sysctl_ctx_list *ctx" -.Fa "struct sysctl_oid_list *parent" -.Fa "int number" -.Fa "NAME" -.Fa "int access" -.Fa "char *arg" -.Fa "0" -.Fa "char *descr" -.Fc -.Ft struct sysctl_oid * -.Fo SYSCTL_ADD_INT -.Fa "struct sysctl_ctx_list *ctx" -.Fa "struct sysctl_oid_list *parent" -.Fa "int number" -.Fa "NAME" -.Fa "int access" -.Fa "int *arg" -.Fa "0" -.Fa "char *descr" -.Fc -.Ft struct sysctl_oid * -.Fo SYSCTL_ADD_UINT -.Fa "struct sysctl_ctx_list *ctx" -.Fa "struct sysctl_oid_list *parent" -.Fa "int number" -.Fa "NAME" -.Fa "int access" -.Fa "unsigned int *arg" -.Fa "0" -.Fa "char *descr" -.Fc -.Ft struct sysctl_oid * -.Fo SYSCTL_ADD_LONG -.Fa "struct sysctl_ctx_list *ctx" -.Fa "struct sysctl_oid_list *parent" -.Fa "int number" -.Fa "NAME" -.Fa "int access" -.Fa "long *arg" -.Fa "0" -.Fa "char *descr" -.Fc -.Ft struct sysctl_oid * -.Fo SYSCTL_ADD_ULONG -.Fa "struct sysctl_ctx_list *ctx" -.Fa "struct sysctl_oid_list *parent" -.Fa "int number" -.Fa "NAME" -.Fa "int access" -.Fa "unsigned long *arg" -.Fa "0" -.Fa "char *descr" -.Fc -.Ft struct sysctl_oid * -.Fo SYSCTL_ADD_OPAQUE -.Fa "struct sysctl_ctx_list *ctx" -.Fa "struct sysctl_oid_list *parent" -.Fa "int number" -.Fa "NAME" -.Fa "int access" -.Fa "void *arg" -.Fa "size_t *len" -.Fa "char *descr" -.Fc -.Ft struct sysctl_oid * -.Fo SYSCTL_ADD_STRUCT -.Fa "struct sysctl_ctx_list *ctx" -.Fa "struct sysctl_oid_list *parent" -.Fa "int number" -.Fa "NAME" -.Fa "int access" -.Fa "struct TYPE *arg" -.Fa "TYPE" -.Fa "char *descr" -.Fc -.Ft struct sysctl_oid * -.Fo SYSCTL_ADD_PROC -.Fa "struct sysctl_ctx_list *ctx" -.Fa "struct sysctl_oid_list *parent" -.Fa "int number" -.Fa "NAME" -.Fa "int access" -.Fa "0" -.Fa "0" -.Fa "int (*handler) (SYSCTL_HANDLER_ARGS)" -.Fa "char *format" -.Fa "char *descr" -.Fc -.Sh DESCRIPTION -These functions and macros provide an interface -for creating and deleting sysctl oids at runtime -(e.g. during lifetime of a module). -The alternative method, -based on linker sets (see -.Aq sys/linker_set.h -and -.\" XXX Manual pages should avoid referencing source files -.Pa src/sys/kern/kern_sysctl.c -for details), only allows creation and deletion -on module load and unload respectively. -.Pp -Dynamic oids of type -.Dv CTLTYPE_NODE -are reusable -so that several code sections can create and delete them, -but in reality they are allocated and freed -based on their reference count. -As a consequence, -it is possible for two or more code sections -to create partially overlapping trees that they both can use. -It is not possible to create overlapping leaves, -nor to create different child types with the name name and parent. -.Pp -Newly created oids are connected to their parent nodes. -In all these functions and macros -(with the exception of -.Fn sysctl_remove_oid ) , -one of the required parameters is -.Fa parent , -which points to the head of the parent's list of children. -.Pp -Most top level categories are created statically. -When connecting to existing static oids, -this pointer can be obtained with the -.Fn SYSCTL_STATIC_CHILDREN -macro, where the -.Fa OID_NAME -argumwent is name of the parent oid of type -.Dv CTLTYPE_NODE -(i.e. the name displayed by -.Xr sysctl 8 , -preceded by underscore, and with all dots replaced with underscores). -.Pp -When connecting to an existing dynamic oid, this pointer -can be obtained with the -.Fn SYSCTL_CHILDREN -macro, where the -.Fa oidp -argument points to the parent oid of type -.Dv CTLTYPE_NODE . -.Pp -The -.Fn sysctl_add_oid -function creates raw oids of any type. -If the oid is successfuly created, -the function returns a pointer to it; -otherwise it returns -.Dv NULL . -Many of the arguments for -.Fn sysctl_add_oid -are common to the macros. -The arguments are as follows: -.Bl -tag -width handler -.It Fa ctx -A pointer to an optional sysctl context, or -.Dv NULL . -See -.Xr sysctl_ctx_init 9 -for details. -Programmers are strongly advised to use contexts -to organize the dynamic oids which they create, -unless special creation and deletion sequences are required. -If -.Fa ctx -is not -.Dv NULL , -the newly created oid will be added to this context -as its first entry. -.It Fa parent -A pointer to a -.Li struct sysctl_oid_list , -which is the head of the parent's list of children. -.It Fa number -The oid number that will be assigned to this oid. -In almost all cases this should be set to -.Dv OID_AUTO , -which will result in the assignment of the next available oid number. -.It Fa name -The name of the oid. -The newly created oid will contain a copy of the name. -.It Fa kind -The kind of oid, -specified as a bitmask of the type and access values defined in the -.Aq sys/sysctl.h -header file. -Oids created dynamically always have the -.Dv CTLTYPE_DYN -flag set. -Access flags specify whether this oid is read-only or read-write, -and whether it may be modified by all users -or by the supseruser only. -.It Fa arg1 -A pointer to any data that the oid should reference, or -.Dv NULL . -.It Fa arg2 -The size of -.Fa arg1 , -or 0 if -.Fa arg1 -is -.Dv NULL . -.It Fa handler -A pointer to the function -that is responsible for handling read and write requests -to this oid. -There are several standard handlers -that support operations on nodes, -integers, strings and opaque objects. -It is possible also to define new handlers using the -.Fn SYSCTL_ADD_PROC -macro. -.It Fa format -A pointer to a string -which specifies the format of the oid symbolically. -This format is used as a hint by -.Xr sysctl 8 -to apply proper data formatting for display purposes. -Currently used format names are: -.Dq N -for node, -.Dq A -for -.Li "char *" , -.Dq I -for -.Li "int" , -.Dq IU -for -.Li "unsigned int" , -.Dq L -for -.Li "long" , -.Dq LU -for -.Li "unsigned long" -and -.Dq S,TYPE -for -.Li "struct TYPE" -structures. -.It Fa descr -A pointer to a textual description of the oid. -.El -.Pp -The -.Fn sysctl_remove_oid -function removes a dynamically created oid from the tree, -optionally freeing its resources. -It takes the following arguments: -.Bl -tag -width recurse -.It Fa oidp -A pointer to the dynamic oid to be removed. -If the oid is not dynamic, or the pointer is -.Dv NULL , -the function returns -.Er EINVAL . -.It Fa del -If non-zero, -.Fn sysctl_remove_oid -will try to free the oid's resources -when the reference count of the oid becomes zero. -However, if -.Fa del -is set to 0, -the routine will only deregister the oid from the tree, -without freeing its resources. -This behaviour is useful when the caller expects to rollback -(possibly partially failed) -deletion of many oids later. -.It Fa recurse -If non-zero, attempt to remove the node and all its children. -If -.Pa recurse -is set to 0, -any attempt to remove a node that contains any children -will result in a -.Er ENOTEMPTY -error. -.Em "WARNING: use recursive deletion with extreme caution!" -Normally it should not be needed if contexts are used. -Contexts take care of tracking inter-dependencies -between users of the tree. -However, in some extreme cases it might be necessary -to remove part of the subtree no matter how it was created, -in order to free some other resources. -Be aware, though, that this may result in a system -.Xr panic 9 -if other code sections continue to use removed subtrees. -.El -.Pp -.\" XXX sheldonh finished up to here -Again, in most cases the programmer should use contexts, -as described in -.Xr sysctl_ctx_init 9 , -to keep track of created oids, -and to delete them later in orderly fashion. -.Pp -There is a set of macros defined -that helps to create oids of given type. -.Bl -tag -width SYSCTL_ADD_STRINGXX -They are as follows: -.It Fn SYSCTL_ADD_OID -creates a raw oid. -This macro is functionally equivalent to the -.Fn sysctl_add_oid -function. -.It Fn SYSCTL_ADD_NODE -creates an oid of type -.Dv CTLTYPE_NODE , -to which child oids may be added. -.It Fn SYSCTL_ADD_STRING -creates an oid that handles a zero-terminated character string. -.It Fn SYSCTL_ADD_INT -creates an oid that handles an -.Li int -variable. -.It Fn SYSCTL_ADD_UINT -creates an oid that handles an -.Li unsigned int -variable. -.It Fn SYSCTL_ADD_LONG -creates an oid that handles a -.Li long -variable. -.It Fn SYSCTL_ADD_ULONG -creates an oid that handles an -.Li unsigned long -variable. -.It Fn SYSCTL_ADD_OPAQUE -creates an oid that handles any chunk of opaque data -of the size specified by the -.Fa len -argument, -which is a pointer to a -.Li "size_t *" . -.It Fn SYSCTL_ADD_STRUCT -creates an oid that handles a -.Li "struct TYPE" -structure. -The -.Fa format -parameter will be set to -.Dq S,TYPE -to provide proper hints to the -.Xr sysctl 8 -utlity. -.It Fn SYSCTL_ADD_PROC -creates an oid with the specified -.Pa handler -function. -The handler is responsible for handling read and write requests -to the oid. -This oid type is especially useful -if the kernel data is not easily accessible, -or needs to be processed before exporting. -.El -.Sh EXAMPLES -The following is an example of -how to create a new top-level category -and how to hook up another subtree to an existing static node. -This example does not use contexts, -which results in tedious management of all intermediate oids, -as they need to be freed later on: -.Bd -literal -#include <sys/sysctl.h> - ... -/* Need to preserve pointers to newly created subtrees, to be able - * to free them later. - */ -struct sysctl_oid *root1, *root2, *oidp; -int a_int; -char *string = "dynamic sysctl"; - ... - -root1 = SYSCTL_ADD_NODE( NULL, SYSCTL_STATIC_CHILDREN(/* tree top */), - OID_AUTO, newtree, CTFLAG_RW, 0, "new top level tree"); -oidp = SYSCTL_ADD_INT( NULL, SYSCTL_CHILDREN(root1), - OID_AUTO, newint, CTLFLAG_RW, &a_int, 0, "new int leaf"); - ... -root2 = SYSCTL_ADD_NODE( NULL, SYSCTL_STATIC_CHILDREN(_debug), - OID_AUTO, newtree, CTFLAG_RW, 0, "new tree under debug"); -oidp = SYSCTL_ADD_STRING( NULL, SYSCTL_CHILDREN(root2), - OID_AUTO, newstring, CTLFLAG_R, string, 0, "new string leaf"); -.Ed -.Pp -This example creates the following subtrees: -.Bd -literal -offset indent -debug.newtree.newstring -newtree.newint -.Ed -.Pp -.Em "Care should be taken to free all oids once they are no longer needed!" -.Pp -.Sh SEE ALSO -.Xr sysctl 8 , -.Xr sysctl_ctx_free 9 , -.Xr sysctl_ctx_init 9 -.Sh HISTORY -These functions first appeared in -.Fx 5.0 . -.Sh AUTHORS -.An Andrzej Bialecki Aq abial@FreeBSD.org -.Sh BUGS -Sharing nodes between many code sections -causes interdependencies that sometimes may lock the resources. -For example, -if module A hooks up a subtree to an oid created by module B, -module B will be unable to delete that oid. -These issues are handled properly by sysctl contexts. -.Pp -Many operations on the tree involve traversing linked lists. -For this reason, oid creation and removal is relatively costly. diff --git a/share/man/man9/sysctl_ctx_init.9 b/share/man/man9/sysctl_ctx_init.9 deleted file mode 100644 index 9d7a8638940c..000000000000 --- a/share/man/man9/sysctl_ctx_init.9 +++ /dev/null @@ -1,244 +0,0 @@ -.\" -.\" Copyright (c) 2000, Andrzej Bialecki <abial@freebsd.org> -.\" All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. The name of the author may not be used to endorse or promote products -.\" derived from this software without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" $FreeBSD$ -.\" -.Dd Jul 15, 2000 -.Dt SYSCTL_CTX_INIT 9 -.Os -.Sh NAME -.Nm sysctl_ctx_init , -.Nm sysctl_ctx_free , -.Nm sysctl_ctx_entry_add , -.Nm sysctl_ctx_entry_find , -.Nm sysctl_ctx_entry_del -.Nd sysctl context for managing dynamically created sysctl oids. -.Sh SYNOPSIS -.Fd #include <sys/sysctl.h> -.Ft int -.Fo sysctl_ctx_init -.Fa "struct sysctl_ctx_list *clist" -.Fc -.Ft int -.Fo sysctl_ctx_free -.Fa "struct sysctl_ctx_list *clist" -.Fc -.Ft struct sysctl_ctx_entry * -.Fo sysctl_ctx_entry_add -.Fa "struct sysctl_ctx_list *clist" -.Fa "struct sysctl_oid *oidp" -.Fc -.Ft struct sysctl_ctx_entry * -.Fo sysctl_ctx_entry_find -.Fa "struct sysctl_ctx_list *clist" -.Fa "struct sysctl_oid *oidp" -.Fc -.Ft int -.Fo sysctl_ctx_entry_del -.Fa "struct sysctl_ctx_list *clist" -.Fa "struct sysctl_oid *oidp" -.Fc -.Sh DESCRIPTION -These functions provide an interface -for managing dynamically created oids. -The sysctl context is responsible for keeping track of created oids, -as well as their proper removal when needed. -It adds a simple transactional aspect to oid removal operations; -i.e. if a removal operation fails part way, -it is possible to roll back the sysctl tree -to its previous state. -.Pp -The -.Fn sysctl_ctx_init -function initializes a sysctl context. -The -.Fa clist -argument must point to an already allocated variable. -A context -.Em must -be initialized before use. -Once it is initialized, -a pointer to the context can be passed as an argument to all the -.Fa SYSCTL_ADD_* -macros (see -.Xr sysctl_add_oid 9 ) , -and it will be updated with entries pointing to newly created oids. -.Pp -Internally, the context is represented as a -.Xr queue 3 -TAILQ linked list. -The list consists of -.Li struct sysctl_ctx_entry -entries: -.Bd -literal -offset indent -struct sysctl_ctx_entry { - struct sysctl_oid *entry; - TAILQ_ENTRY(sysctl_ctx_entry) link; -}; - -TAILQ_HEAD(sysctl_ctx_list, sysctl_ctx_entry); -.Ed -.Pp -Each context entry points to one dynamic oid that it manages. -Newly created oids are always inserted in the front of the list. -.Pp -The -.Fn sysctl_ctx_free -function removes the context and associated oids it manages. -If the function completes successfuly, -all managed oids have been unregistered -(removed from the tree) -and freed, -together with all their allocated memory, -and the entries of the context have been freed as well. -.Pp -The removal operation is performed in two steps. -First, for each context entry, the function -.Xr sysctl_remove_oid 9 -is executed, with parameter -.Fa del -set to 0, which inhibits the freeing of resources. -If there are no errors during this step, -.Fn sysctl_ctx_free -proceeds to the next step. -If the first step fails, -all unregistered oids associated with the context are registered again. -.Pp -.Em Note : -in most cases, the programmer specifies -.Dv OID_AUTO -as the oid number when creating an oid. -However, during registration of the oid in the tree, -this number is changed to the first available number -greater than 99. -If the first step of context deletion fails, -re-registration of the oid does not change the already assigned oid number -(which is different from OID_AUTO). -This ensures that re-registered entries -maintain their original positions in the tree. -.Pp -The second step actually performs the deletion of the dynamic oids. -.Xr sysctl_remove_oid 9 -iterates through the context list, -starting from beginning (i.e. the newest entries). -.Em Important : -this time, the function not only deletes the oids from the tree, -but also frees their memory (provided that oid_refcnt == 0), -as well as the memory of all context entries. -.Pp -The -.Fn sysctl_ctx_entry_add -function allows the addition of an existing dynamic oid to a context. -.Pp -The -.Fn sysctl_ctx_entry_del -function removes an entry from the context. -.Em Important : -in this case, only the corresponding -.Li struct sysctl_ctx_entry -is freed, but the -.Fa oidp -pointer remains intact. -Thereafter, the programmer is responsible for managing the resources -allocated to this oid. -.Pp -The -.Fn sysctl_ctx_entry_find -function searches for a given -.Fa oidp -witin a context list, -either returning a pointer to the -.Fa struct sysctl_ctx_entry -found, -or -.Dv NULL . -.Sh EXAMPLES -The following is an example of how to create a new top-level category -and how to hook up another subtree to an existing static node. -This example uses contexts to keep track of the oids. -.Bd -literal -#include <sys/sysctl.h> - ... -struct sysctl_ctx_list clist; -struct sysctl_oid *oidp; -int a_int; -char *string = "dynamic sysctl"; - ... - -sysctl_ctx_init(&clist); -oidp = SYSCTL_ADD_NODE( &clist, SYSCTL_STATIC_CHILDREN(/* tree top */), - OID_AUTO, newtree, CTFLAG_RW, 0, "new top level tree"); -oidp = SYSCTL_ADD_INT( &clist, SYSCTL_CHILDREN(oidp), - OID_AUTO, newint, CTLFLAG_RW, &a_int, 0, "new int leaf"); - ... -oidp = SYSCTL_ADD_NODE( &clist, SYSCTL_STATIC_CHILDREN(_debug), - OID_AUTO, newtree, CTFLAG_RW, 0, "new tree under debug"); -oidp = SYSCTL_ADD_STRING( &clist, SYSCTL_CHILDREN(oidp), - OID_AUTO, newstring, CTLFLAG_R, string, 0, "new string leaf"); - ... -/* Now we can free up the oids */ -if(sysctl_ctx_free(&clist)) { - printf("can't free this context - other oids depend on it"); - return(ENOTEMPTY); -} else { - printf("Success!\\n"): - return(0); -} -.Ed -.Pp -This example creates the following subtrees: -.Bd -literal -offset indent -debug.newtree.newstring -newtree.newint -.Ed -.Pp -Note that both trees are removed, and their resources freed, -through one -.Fn sysctl_ctx_free -call, which starts by freeing the newest entries (leaves) -and then proceeds to free the older entries (in this case the nodes). -.Sh SEE ALSO -.Xr queue 3 , -.Xr sysctl 8 , -.Xr sysctl_add_oid 9 , -.Xr sysctl_remove_oid 9 -.Sh HISTORY -These functions first appeared in -.Fx 5.0 . -.Sh AUTHORS -.An Andrzej Bialecki Aq abial@FreeBSD.org -.Sh BUGS -The current removal algorithm is somewhat heavy. -In the worst case, -all oids need to be unregistered, registered again, -and then unregistered and deleted. -However, the algorithm does guarantee transactional properties -for removal operations. -.Pp -All operations on contexts involve linked list traversal. -For this reason, -creation and removal of entries is relatively costly. |