Re: setting quotas _inside_ a jail for users _inside_ a jail

2002-09-01 Thread Robert Watson


On Fri, 30 Aug 2002, Patrick Thomas wrote:

 I realize the difficulties in trying to use quotas on the _host_
 system to limit the size of jails on the host system - userid mapping,
 etc.  This is not what I am asking.

 I wonder, is it possible for the root user of a jail to set quotas
 _inside_ her jail for users _inside_ her jail ?  Can anyone simply
 confirm or deny that this is possible ?

 Simply following normal protocol does not work, because if you place
 filesystem entries into /etc/fstab inside the jail, the jail will no
 longer start, as it does not have permission to mount or otherwise
 manipulate those filesystems.

Other than the access control checks in the quota code being influenced by
the jail, there really is no relationship between jails and quotas.
Jails are solely a property of processes and other credential-bearing
kernel objects.  Persistent and transient quota information is stored
relative to uids and gids, and quotas are enforced based on those elements
of the process credential, and are not impacted by the jail field.  This
means that if a file system is shared by two jails, and a particular uid
is in use in both jails, both sets of processes will be impacted by the
same quota.

Privileged users can perform quota management calls on any file system
they can name via a visible file object.  If quota management calls were
permitted from jail, they could likewise be performed on any file system
visible in the jail.  If only appropriate file systems are visible from
the jail, you could add PRISON_ROOT to the flags field of the relevant
suser call.  If you expose file systems to the jail that you don't want
the root user in the jail to set quotas on, you may be out of luck.  I
take it from your description that you're interested in imposing quotas on
the users in the jail, not quotas on the jail itself?

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



anyone seen this 5.0 panic on reboot?

2002-09-01 Thread Matthew Jacob


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x8d
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc02c7d24
stack pointer   = 0x10:0xd26579ac
frame pointer   = 0x10:0xd26579dc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 354 (halt)
kernel: type 12 trap, code=0
Stopped at

0xc02c7d24 is

0xc02c7d24 ithread_schedule+244:  cmpl $0x27,0x8c(%esi)





To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Ðàáîòà â ×åøñêîé Ðåñïóáëèêå !

2002-09-01 Thread info

Ïîïðîáóéòå íàéòè ðàáîòó â ×åøñêîé Ðåñïóáëèêå!

Åñëè ó Âàñ íåò ïîäòâåðæäåííîãî âûñøåãî îáðàçîâàíèÿ òåõíè÷åñêîãî, èëè
ýêîíîìè÷åñêîãî íàïðàâëåíèÿ.
Åñëè Âû àáñîëþòíî äîâîëüíû Âàøèì ðàáîòîäàòåëåì è óñëîâèÿìè îïëàòû.
Åñëè âàñ óñòðàèâàåò ýêîíîìè÷åñêàÿ è êðèìèíàëüíàÿ ñèòóàöèÿ â Âàøåì
ãîðîäå/ñòðàíå.
Òî ýòî îáðàùåíèå íå äëÿ Âàñ, è Âû ìîæåòå åãî ñïîêîéíî óäàëèòü.

 ðåçóëüòàòå îòòîêà èíæåíåðñêèõ êàäðîâ íà çàïàä, â ×åõèè îáðàçîâàëñÿ
ïîâûøåííûé ñïðîñ íà êâàëèöèðîâàííûõ ñïåöèàëèñòîâ ñ âûñøèì îáðàçîâàíèåì.

* Ó Âàñ âûñøåå îáðàçîâàíèå òåõíè÷åñêîãî, èëè ýêîíîìè÷åñêîãî íàïðàâëåíèÿ?
* Âû íå ìîæåòå íàéòè ðàáîòó?
* Âàñ íå óñòðàèâàåò óñëîâèÿ îïëàòû, èëè ñðåäà îáèòàíèÿ?

Ïîïðîáóéòå íàéòè ðàáîòó â ×åøñêîé Ðåñïóáëèêå!

Óñëîâèÿ îïëàòû:
- íà÷àëüíàÿ çàðïëàòà - 12.000,- - 15.000,- êðîí (400,- - 500,- Åâðî)
- ïðè óñïåøíîì âûïîëíåíèè ïðîèçâîäñòâåííûõ çàäà÷ è ïîäòâåðæäåíèÿ
êâàëèôèêàöèè çàðïëàòà - 40.000,- - 50.000,- êðîí (1.350,- - 1.600,- Åâðî).
Äëÿ ñïðàâêè - ïðîæèòî÷íûé ìèíèìóì â ×åõèè ñîñòàâëÿåò 4.500,- Êðîí ÷åøñêèõ.

Ïðè ýòîì íå çàáûâàéòå, ÷òî ñ âñòóïëåíèåì ×åõèè â Åâðîïåéñêèé Ñîþç, çàðïëàòà
áóäåò ðàñòè, à êóðñ Åâðî ê Êðîíå ïîíèæàòüñÿ!

×åøñêèå çàâîäû è èññëåäîâàòåëüñêèå îðãàíèçàöèè æäóò Âàñ!

Ìåæäóíàðîäíûé Èíôîðìàöèîííûé öåíòð (INFOCENTR) ïðåäëàãàåò Âàøåìó âíèìàíèþ
ýêñêëþçèâíóþ ïðîãðàììó ïî àäàïòàöèè è ïîäáîðó ðàáî÷åãî ìåñòà â ×åøñêîé Ðåñïóáëèêå.


Ïðîäîëæèòåëüíîñòü ïðîãðàììû 4 - 5 ìåñÿöåâ (â ò.÷. 3-õ ìåñÿ÷íûå êóðñû ÿçûêà +
1 ìåñ. ñòàæèðâîêà)
 ñòîèìîñòü ïðîãðàììû âõîäèò:
1/ Ïîäáîð ðàáî÷åãî ìåñòà.
2/ Êóðñû ÷åøñêîãî ÿçûêà.
3/ Ñòàæèðîâêà íà âûáðàííîì ïðåäïðèÿòèè.
4/ Îïëà÷åííîå ïðîæèâàíèå íà âñå âðåìÿ íàõîæäåíèÿ â ×åõèè.
5/ 3-õ ìåñÿ÷íîå ïðèãëàøåíèå â ×åõèþ.
6/ Áåñïëàòíîå ñîïðîâîæäåíèå êâàëèôèöèðîâàííûì ëè÷íûì êîíñóëüòàíòîì! Âû
âñåãäà ñìîæåòå îáàðòèòüñÿ ê íàøèì ïðåäñòàâèòåëÿì â ×åõèè äëÿ ðàçúÿñíåíèÿ
îñíîâíûõ þðèäè÷åñêèõ, õîçÿéñòâåííûõ è áûòîâûõ âîïðîñîâ.

Ñòîèìîñòü ïðîãðàììû:
- ñ ïðîæèâàíèåì (â ò.÷. çàâòðàê) - 2.300,- äîë. ÑØÀ
- ñ ïðîæèâàíèåì (áåç çàâòðàêà) - 1.700,- äîë. ÑØÀ
- áåç ïðîæèâàíèÿ - 1.150,- äîë. ÑØÀ

Ïðèìå÷àíèÿ.

1/ Ïðèåì àíêåò è àíàëèç âîçìîæíûõ âàðèàíòîâ ïî òðóäîóñòðîéñòâó ïðîèçâîäèòñÿ
ÁÅÑÏËÀÒÍÎ.
2/ Îáÿçàòåëüñòâ ïî îòâåòàì íà âñå ïðèñëàííûå àíêåòû, èëè íà èíûå îáðàùåíèÿ,
ìû ÍÅ ÍÅÑÅÌ!
3/ Îòâåòû íà ïðèñëàííûå àíêåòû, ñ óêàçàíèåì êîíòàêòîâ íà íàøèõ
ïðåäñòàâèòåëåé, áóäóò ïîñëàíû â ïîðÿäêå èõ îáðàáîòêè è òîëüêî íà êîíòàêòíûé
å-ìåéë.
4/ Îïëàòà çà âñþ ïðîãðàììó ìîæåò áûòü ïðîâåäåíà íà îñíîâàíèè îôèöèàëüíîãî
ñ÷åòà-ôàêòóðû çà êóðñû ÷åøñêîãî ÿçûêà â àêêðåäèòîâàííîì ÷åøñêîì ó÷åáíîì
çàâåäåíèè, èëè ÷åðåç ñèñòåìó Àíåëèê. Îïëàòà óñëóã çà ïåðåâîä ïðîèçâîäèòñÿ
îòïðàâèòåëåì.
5/ Ïîñëå ïîëó÷åíèÿ îïëàòû ñ Âàìè áóäåò ñîãëàñîâàíà ïðîãðàììà ñòàæèðîâêè,
îñíîâîé êîòîðîé áóäåò ó÷åáíûé ïëàí êóðñîâ ÷åøñêîãî ÿçûêà. Ïîñëå óòâåðæäåíèÿ
ñðîêîâ Âàøåãî ïðèåçäà, Âàì áóäåò ïðèñëàíî îôèöèàëüíîå ïðèãëàøåíèå íà ó÷åáó
äëÿ ïîëó÷åíèÿ ìíîãîðàçîâîé 3-õ ìåñÿ÷íîé âèçû â ÷åøñêîì Êîíñóëüñòâå. ÎÏËÀÒÀ
ÂÈÇÎÂÎÃÎ ÑÁÎÐÀ  ÑÒÎÈÌÎÑÒÜ ÎÁÓ×ÅÍÈß ÍÅ ÂÕÎÄÈÒ!
6/  ñëó÷àå Âàøåé íåâîçìîæíîñòè ïðèåõàòü â ×åõèþ ïî íåçàâèñÿùèì îò íàñ
ïðè÷èíàì, ïîñëå ñîãëàñîâàíèÿ äàòû íà÷àëà îáó÷åíèÿ, Èíôîöåíòð íå íåò
îáÿçàòåëüñòâ ïî ïîëíîìó âîçâðàòó ïîëó÷åííûõ äåíåã!

Åñëè Âàñ çàèíòåðåñîâàëî íàøå ïðåäëîæåíèå, ïîæàëóéñòà, îòâåòüòå íà àíêåòó è
îòïðàâüòå íà ìåéë: mailto:[EMAIL PROTECTED] (òîëüêî äëÿ àíêåò!):

1/ Ô.È.Î.
2/ Äàòà ðîæäåíèÿ
3/ Ñïåöèàëüíîñòü ïî äèïëîìó
4/ Íàçâàíèå, àäðåñ ÂÓÇà/îâ
5/ Äàòà îêîí÷àíèÿ ÂÓÇà/îâ
6/ Ñòàæ ðàáîòû ïî ñïåöèàëüíîñòè, ïîäòâåðæäåííûé â òðóäîâîé êíèæêå.
7/ Íàñòîÿùåå ìåñòî ðàáîòû, äîëæíîñòü
8/ Çíàíèå èíîñòðàííûõ ÿçûêîâ
9/ Ñåìåéíîå ïîëîæåíèå
10/ Íàëè÷èå äåòåé, èõ êîëè÷åñòâî
11/ Ïðî÷åå (ïî Âàøåìó óñìîòðåíèþ)
12/ Êîíòàêòíûé å-ìåéë.
Ñ óâàæåíèåì,
Ìåæäóíàðîäíûé Èíôîðìàöèîííî öåíòð â ×åõèè (INFOCENTR)
mailto:[EMAIL PROTECTED] (òîëüêî äëÿ àíêåò!)
Tel/fax: +420 38 610 6147

Ñåðãåé Âèêòîðîâè÷  [EMAIL PROTECTED]

Ïðèìå÷àíèå.

ÌÀÑÑÎÂÛÅ ÐÀÑÑÛËÊÈ ÍÅ ÏÐÎÒÈÂÎÐÅ×ÀÒ ÇÀÊÎÍÎÄÀÒÅËÜÑÒÂÓ ÐÔ è Óêðàèíû.
Äîïîëíèòåëüíóþ èíôîðìàöèþ î ïðàâîâûõ àñïåêòàõ e-mail ðàññûëîê Âû
ìîæåòå ïîëó÷èòü íà ñàéòå Îáùåñòâåííîãî Ñîâåòà ïî
Èíôîðìàöèîííîìó Îáìåíó â Ñåòè http://www.osios.org/ 

Èíôîðìàöèÿ ïî âîïðîñó ðàññûëêè  îáðàùàòñÿ ïî àäðåñó mailto:[EMAIL PROTECTED]

 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: setting quotas _inside_ a jail for users _inside_ a jail

2002-09-01 Thread Patrick Thomas


No, sorry I think that I was misunderstood - here is my situation:

- I have a host machine with no users - just root.
- on that host machine I have a vn-backed FS 500 megs in size
- on that vn-backed FS, I run a jail - and no other jails share that
vn-backed FS (although other jails may share the underlying actual disk FS
that the vn is on...)

Now, I die in a car accident and nobody ever logs into the host system
again or touches anything on the _host system_.

Can the root user of the _jail running on the host system_ set up quotas
for her users ?  Let's assume the root user and all her other users don't
even know it is a jail - as far as they are concerned, it's just their
freebsd machine.

So the question is, can this root user set up quotas ?  And if so, some
hints on exactly what needs to go into /etc/fstab _inside their jail_,
since specifying anything in there seems to have the side effects of:

a) not working as expected
b) causing the jail not to be startable.

thanks,

PT

On Sun, 1 Sep 2002, Robert Watson wrote:


 On Fri, 30 Aug 2002, Patrick Thomas wrote:

  I realize the difficulties in trying to use quotas on the _host_
  system to limit the size of jails on the host system - userid mapping,
  etc.  This is not what I am asking.
 
  I wonder, is it possible for the root user of a jail to set quotas
  _inside_ her jail for users _inside_ her jail ?  Can anyone simply
  confirm or deny that this is possible ?
 
  Simply following normal protocol does not work, because if you place
  filesystem entries into /etc/fstab inside the jail, the jail will no
  longer start, as it does not have permission to mount or otherwise
  manipulate those filesystems.

 Other than the access control checks in the quota code being influenced by
 the jail, there really is no relationship between jails and quotas.
 Jails are solely a property of processes and other credential-bearing
 kernel objects.  Persistent and transient quota information is stored
 relative to uids and gids, and quotas are enforced based on those elements
 of the process credential, and are not impacted by the jail field.  This
 means that if a file system is shared by two jails, and a particular uid
 is in use in both jails, both sets of processes will be impacted by the
 same quota.

 Privileged users can perform quota management calls on any file system
 they can name via a visible file object.  If quota management calls were
 permitted from jail, they could likewise be performed on any file system
 visible in the jail.  If only appropriate file systems are visible from
 the jail, you could add PRISON_ROOT to the flags field of the relevant
 suser call.  If you expose file systems to the jail that you don't want
 the root user in the jail to set quotas on, you may be out of luck.  I
 take it from your description that you're interested in imposing quotas on
 the users in the jail, not quotas on the jail itself?

 Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
 [EMAIL PROTECTED]  Network Associates Laboratories




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: More dynamic KVA_SPACE

2002-09-01 Thread Terry Lambert

Brandon D. Valentine wrote:
[ ... AMD ... ]
 In all seriousness I'm not sure where he got the idea that these things
 were supposed to be out a while ago but I don't recall any claims from
 AMD to confirm that.  If anything AMD's development cycle for these
 things makes Intel's development cycle for IA64 downright embarassing.
 The x86-64 silicon will be on the market on schedule and according to
 the benchmarks I've seen will be doubling the IPC of AMD's already
 impressive x86-32 hardware.  Plus, I hear they run cool, which would be
 a pleasant change from the current Athlons and might actually make AMD
 processors a viable option in dense environments.


At one point in time, I was working on a product that really,
really cared about more than 4G of linearlly addressable memory
(i.e. PAE need not apply, since only a moron would implement the
particular product that way, given the overall requirements).

The original claims for the tape-out on the x86-64 from AMD so
that this could happen were September 2001, with sample units
1Q2002.  The AMD schedule slipped.

I realize that schedule slippage is practically the norm, these
days, so nobody questions it any more, but that doesn't make it
any less annoying for people who try to do what they say when
they say.

You'll notice that I *clearly* identified the posting as a rant.
8-).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: setting quotas _inside_ a jail for users _inside_ a jail

2002-09-01 Thread Terry Lambert

Patrick Thomas wrote:
 No, sorry I think that I was misunderstood - here is my situation:
 
 - I have a host machine with no users - just root.
 - on that host machine I have a vn-backed FS 500 megs in size
 - on that vn-backed FS, I run a jail - and no other jails share that
 vn-backed FS (although other jails may share the underlying actual disk FS
 that the vn is on...)

This is the magic part: quotas are per-UID, per-FS, but Robert is
correct about their relationship to jails.

What you failed to communicate to Robert is that you have also
arbitrarily defined FS's to be per-jail, which, in the limit,
will (effectively) make quota per-UID, per-jail.

Most people don't use vn-backed FSs for jails.


 Now, I die in a car accident and nobody ever logs into the host system
 again or touches anything on the _host system_.
 
 Can the root user of the _jail running on the host system_ set up quotas
 for her users ?  Let's assume the root user and all her other users don't
 even know it is a jail - as far as they are concerned, it's just their
 freebsd machine.

The answer is yes.  The method of doing this was already posted
in this thread.  You have to do evil things to the fstab within the
jail itself, and outside the jail, but if you wave the correct dead
chicken, it works.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: why does this sendmail connection take so long?

2002-09-01 Thread Eric Parusel

 On Thu, Aug 29, 2002 at 11:27:07AM -0700, Gregory Neil Shapiro wrote:
  That explains it.  You have a record pointing localhost.example.org at
::1

 Unfortunately this is our default configuration:

 # $FreeBSD: src/etc/hosts,v 1.15 2001/12/11 22:36:10 rwatson Exp $
 ..snip..
 ::1 localhost localhost.my.domain
 127.0.0.1 localhost localhost.my.domain

 This has caused me trouble before and I've been  close to reversing the
 IPv6 and IPv4 lines...

I swapped them since I have log_in_vain turned on, and I didn't like the
extra alerts I was getting.
Works great for me...
Now just if I could get Sendmail to not do those dang identd checks all the
time...
The less false alarms that log_in_vain reports, the more safe and cozy I
feel :)

Eric




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message