Re: debugging frequent kernel panics on 8.2-RELEASE

[Jamie Gritton]

On 08/20/11 19:19, Steven Hartland wrote:

- Original Message - From: "Andriy Gapon" 


on 20/08/2011 23:24 Steven Hartland said the following:

- Original Message - From: "Steven Hartland"

Looking through the code I believe I may have noticed a scenario
which could
trigger the problem.

Given the following code:-

static void
prison_deref(struct prison *pr, int flags)
{
struct prison *ppr, *tpr;
int vfslocked;

if (!(flags & PD_LOCKED))
mtx_lock(&pr->pr_mtx);
/* Decrement the user references in a separate loop. */
if (flags & PD_DEUREF) {
for (tpr = pr;; tpr = tpr->pr_parent) {
if (tpr != pr)
mtx_lock(&tpr->pr_mtx);
if (--tpr->pr_uref > 0)
break;
KASSERT(tpr != &prison0, ("prison0 pr_uref=0"));
mtx_unlock(&tpr->pr_mtx);
}
/* Done if there were only user references to remove. */
if (!(flags & PD_DEREF)) {
mtx_unlock(&tpr->pr_mtx);
if (flags & PD_LIST_SLOCKED)
sx_sunlock(&allprison_lock);
else if (flags & PD_LIST_XLOCKED)
sx_xunlock(&allprison_lock);
return;
}
if (tpr != pr) {
mtx_unlock(&tpr->pr_mtx);
mtx_lock(&pr->pr_mtx);
}
}

If you take a scenario of a simple one level prison setup running a
single
process
where a prison has just been stopped.

In the above code pr_uref of the processes prison is decremented. As
this is the
last process then pr_uref will hit 0 and the loop continues instead
of breaking
early.

Now at the end of the loop iteration the mtx is unlocked so other
process can
now manipulate the jail, this is where I think the problem may be.

If we now have another process come in and attach to the jail but
then instantly
exit, this process may allow another kernel thread to hit this same
bit of code
and so two process for the same prison get into the section which
decrements
prison0's pr_uref, instead of only one.

In essence I think we can get the following flow where 1# = process1
and 2# = process2
1#1. prison1.pr_uref = 1 (single process jail)
1#2. prison_deref( prison1,...
1#3. prison1.pr_uref-- (prison1.pr_uref = 0)
1#3. prison1.mtx_unlock <-- this now allows others to change
prison1.pr_uref
1#3. prison0.pr_uref--
2#1. process1.attach( prison1 ) (prison1.pr_uref = 1)
2#2. process1.exit
2#3. prison_deref( prison1,...
2#4. prison1.pr_uref-- (prison1.pr_uref = 0)
2#5. prison1.mtx_unlock <-- this now allows others to change
prison1.pr_uref
2#5. prison0.pr_uref-- (prison1.pr_ref has now been decremented
twice by prison1)

It seems like the action on the parent prison to decrement the
pr_uref is
happening too early, while the jail can still be used and without
the lock on
the child jails mtx, so causing a race condition.

I think the fix is to the move the decrement of parent prison
pr_uref's down
so it only takes place if the jail is "really" being removed. Either
that or
to change the locking semantics so that once the lock is aquired in
this
prison_deref its not unlocked until the function completes.

What do people think?


After reviewing the changes to prison_deref in commit which added
hierarchical
jails, the removal of the lock by the inital loop on the passed in
prison may
be unintentional.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_jail.c.diff?r1=1.101;r2=1.102;f=h



If so the following may be all that's needed to fix this issue:-

diff -u sys/kern/kern_jail.c.orig sys/kern/kern_jail.c
--- sys/kern/kern_jail.c.orig 2011-08-20 21:17:14.856618854 +0100
+++ sys/kern/kern_jail.c 2011-08-20 21:18:35.307201425 +0100
@@ -2455,7 +2455,8 @@
if (--tpr->pr_uref > 0)
break;
KASSERT(tpr != &prison0, ("prison0 pr_uref=0"));
- mtx_unlock(&tpr->pr_mtx);
+ if (tpr != pr)
+ mtx_unlock(&tpr->pr_mtx);
}
/* Done if there were only user references to remove. */
if (!(flags & PD_DEREF)) {


Not sure if this would fly as is - please double check the later block
where
pr->pr_mtx is re-locked.


Your right, and its actually more complex than that. Although changing
it to
not unlock in the middle of prison_deref fixes that race condition it
doesn't
prevent pr_uref being incorrectly decremented each time the jail gets into
the dying state, which is really the problem we are seeing.

If hierarchical prisons are used there seems to be an additional problem
where the counter of all prisons in the hierarchy are decremented, but as
far as I can tell only the immediate parent is ever incremented, so another
reference problem there as well I think.

The following patch I believe fixes both of these issues.

I've testing with debug added and confirmed prison0's pr_uref is maintained
correctly even when a jail hits dying state multiple times.

It essentially reverts the changes to the "if (flags & PD_DEUREF)" by
192895 and moves it to after the jail has been actually removed.

diff -u sys/kern/kern_jail.c.orig sys/kern/kern_jail.c
--- sys/kern/kern_jail.c.orig 2011-08-20 21:17:14.856618854 +0100
+++ sys/kern/kern_jail.c 2011-08-21 01:56:58.429894825 +0100
@@ -2449,27 +2449,16 @@
mtx_lock(&pr->pr_mtx);
/* Decrement the user references in a separate loop. */
if (flags & PD_DEUREF) {
- for

Re: debugging frequent kernel panics on 8.2-RELEASE

[Jamie Gritton]

On 08/21/11 05:01, Steven Hartland wrote:

- Original Message - From: "Jamie Gritton" 

The problem isn't with the conditional locking of tpr in prison_deref.
That locking is actually correct, and there's no race condition.


Are you sure? I do think that unlocking the mtx half way through the
call allows the above scenario to create a race condition, all be it
very briefly, when ignoring the overriding issue.

In addition if the code where changed to so that the pr_uref++ also
maintained the parents uref this would definitely lead to a potential
problems in my mind, especially if you had more than one child prison,
of a given parent, entering the dying state at any one time.

In this case I believe you would have to acquire the locks of all
the parent prisons before it would be safe to precede.


Lock order requires that I unlock the child if I want to lock the
parent. While that does allow periods where neither is locked, it's safe
in this case. There may be multiple processes dying in one jail, or in
multiple children of a single jail. But as long as a parent jail is
locked while decrementing pr_uref, then only one of these simultaneous
prison_deref calls would set pr_uref to zero and continue in the loop to
that prison's parent. This might be mixed with pr_uref being incremented
elsewhere, but that's not a problem either as long as the jail in
question is locked.


The trouble lies in the resurrection of dead jails, as Andriy has noted
(though not just attaching, but also by setting its persist flag causes
the same problem).


I not sure that persistent prisons actually suffer from this in any
different way tbh, as they have an additional uref increment so would
never hit this case unless they have been actively removed and hence
unpersisted first.


Right - both the attach and persist cases are only a problem when a jail
has disappeared. There are various ways for a jail to be removed,
potentially to be kept around but in the dying state, but only two
related ways for it to be resurrected: attaching a new process or
setting the persist flag, both via jail_set with the JAIL_DYING flag passed.


There are two possible fixes to this. One is the patch you've given,
which only decrements a parent jail's pr_uref when the child jail
completely goes away (as opposed to when it loses its last uref). This
provides symmetry with the current way pr_uref is incremented on the
parent, which is only when a jail is created.

The other fix is to increment a parent's pr_uref when a jail is
resurrected, which will match the current logic in prison_deref. I like
the external semantics of this solution: a jail isn't visible if it is
not persistent and has no processes and no *visible* sub-jails, as
opposed to having no sub-jails at all. But this solution ends up pretty
complicated - there are a few places where pr_uref is incremented, where
I might need to increment parent jails' pr_uref as well, much like the
current tpr loop in prison_deref decrements them.


Ahh yes in the hierarchical case my patch would indeed mean that none
persistent parent jails would remain visible even when its last child
jail is in a dying state.

As you say making this not the case would likely require replacing all
instances of pr_uref++ with a prison_uref method that implements the
opposite of the loop in prison_dref should the prisons pr_uref be 0 when
called.


Yes, that's the problem. Maybe not all instances, but at least most have
enough times a jail is unlocked that we can't assume the pr_uref hasn't
been set to zero somewhere else, and so we need to do that loop.


Your solution removes code instead of adding it, which is generally a
good thing. While it does change the semantics of pr_uref in the
hierarchical case at least from what I thought it was, those semantics
haven't been working properly anyway.


Good to know my interpretation was correct, even if I was missing the
visibility factor in the hierarchical case :)


Bjoern, I'm adding you to the CC list for this because the whole pr_uref
thing was your idea (though it was pr_nprocs at the time), so you might
care about the hierarchical semantics of it - or you may not. Also, this
is a panic-inducing bug in current and may interest you for that reason.


 From an admin perspective the current jail dying state does cause
confusion when your not aware of its existence. You ask a jail to stop it
appears to have completed that request, but really hasn't, an generally
due to just a lingering tcp connection.

With the introduction of hierarchical jails that gets a little worse
where a whole series of jails could disappear from normal view only to
be resurrected shortly after. Something to bear in mind when deciding
which solution of the two presented to use.


The good news is that the only time a jail (or perhaps a whole set of
jails) can only come back from the dead when the administra

Re: Fighting with vnet / jails epair and so on

[Jamie Gritton]

On 01/19/12 16:08, Bjoern A. Zeeb wrote:

On 19. Jan 2012, at 22:33 , Philipp Huebner wrote:

On 19/01/12 18:22, Denny Schierz wrote:

hi,

Am 18.01.2012 um 23:21 schrieb Philipp Huebner:


I use 9.0.0 release for host and jail and a generic kernel with
OPTIONS VIMAGE being the only change/addition. No problem.


so, how looks your rc.conf config ? Do you use vimage the tool? I
can't use vimage (as I know) on sparc64.


...

I do not use (and never have) the vimage commandline tool.


Are you sure you (reading and posting here, plural, in general) sure, that
you don't want to read up on freebsd-jail and give the framework a try which
might make your life easier...

http://lists.freebsd.org/pipermail/freebsd-jail/2011-July/thread.html#1568

I am sure Jamie would like feedback and now that 9.0 is done get review
and get it in...

/bz


Actually I think it's high time for Jamie to get off his butt and just
commit the thing.  Reviews will likely follow :-).

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Jail startup/shutdown broken on latest 9-STABLE

[Jamie Gritton]

On 05/24/12 16:30, Mateusz Guzik wrote:

On Thu, May 24, 2012 at 06:20:15PM -0400, Mike Jakubik wrote:

On Fri, 2012-05-25 at 00:13 +0200, Mateusz Guzik wrote:

On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote:

On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote:

On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote:

Hello,

Latest 9-STABLE has introduced some changes that break the ezjail rc
script. On bootup it fails to start, but when i log in via ssh and
manually start it, it works. However i am unable to shut them down
afterwards.


Try this:
http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch

cd /usr/src&&  patch -p1<  patch&&  cd usr.sbin/jail&&  make&&  make install

/usr/src/etc/rc.d/jail script can be just copied over.

Note that your /var/run/jail_* files have broken content (some line from
/etc/rc's output instead of jail id).



Mateusz,

Thanks for the patch, it fixes the startup issue on boot, however
shutting down the jails still does not work. The /var/run files have
garbage in them as you mentioned.

root@jail.local:~# cat /var/run/jail_app.id
/etc/rc: WARNING: $hostname is not set -- see rc.conf(5).


Hostname is set in /etc/rc.conf.


This message is about rc.conf from your jail.

This should be fixed by my change to etc/rc.d/jail, are you sure that
you are running patched version?



Right, i just realized this. I set the hostname in the jailed rc.conf,
now the file contains this:

root@jail.local:~# cat /var/run/jail_app.id
Setting hostname: app.local.

I do not see a link to your jail rc.d script, just the patch.




Patch contains two fixes, for both usr/sbin/jail and etc/rc.d/jail.

Assuming that the patch is still applied to your source tree, just do:
cp /usr/src/etc/rc.d/jail /etc/rc.d/jail

This fixes the jail script to actually store jail id instead of messages
from /etc/rc.

That is, you should be able to stop jails started by new etc/rc.d/jail
script.


I'll get the patch to jail(8) in - thanks for catching that. But I
wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm
going to see if it's /etc/rc.d/jail that needs changing, or if my recent
changes to jail(8) have changed the order in which things are written.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Jail startup/shutdown broken on latest 9-STABLE

[Jamie Gritton]

On 05/24/12 16:59, Mateusz Guzik wrote:

On Thu, May 24, 2012 at 04:46:52PM -0600, Jamie Gritton wrote:

I'll get the patch to jail(8) in - thanks for catching that. But I
wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm
going to see if it's /etc/rc.d/jail that needs changing, or if my recent
changes to jail(8) have changed the order in which things are written.



Yeah, was not sure whether I should change the order or the script. :)

Would not it be better to just create empty persistent jail as first step?
Since in this case only one line will be generated (jid), rc.d script
will be able to just take the output - this seems much less fragile
than the current method. Then of course it would proceed with jexec
running /etc/rc and in the end drop persist flag.

It looks like rc.d script still uses old syntax so this actually may be
less trivial than it sounds. That being said, if this is idea sounds
okay, I can try to come up with a patch this weekend.



There definitely is a difference between old and new jail behavior, not
just in the order of things:

glorfindel# jail -i -c name=foo command="foo"
5
jail: execvp: foo: No such file or directory

vs

glorfindel# /usr/obj`pwd`/jail -i -c name=foo command="foo"
jail: exec foo: No such file or directory
jail: foo: failed
-1

The jail id given back used to correspond to a jail that was created but
no longer exists by the time it's printed (or shortly thereafter). Now
it's a -1 indicating that no jail exists. I think the -1 is more
correct, but perhaps better for CURRENT but not STABLE? And the extra
"foo: failed" is printed by jail, as a generic message when a command
doesn't work out (for the case where the command itself doesn't print
a message).

Hmm ... I'll be pondering this one while I get a bite to eat :-).

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Jail startup/shutdown broken on latest 9-STABLE

[Jamie Gritton]

On 05/24/12 19:23, Mateusz Guzik wrote:

On Thu, May 24, 2012 at 06:47:30PM -0600, Jamie Gritton wrote:

On 05/24/12 16:59, Mateusz Guzik wrote:

On Thu, May 24, 2012 at 04:46:52PM -0600, Jamie Gritton wrote:

I'll get the patch to jail(8) in - thanks for catching that. But I
wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm
going to see if it's /etc/rc.d/jail that needs changing, or if my recent
changes to jail(8) have changed the order in which things are written.



Yeah, was not sure whether I should change the order or the script. :)

Would not it be better to just create empty persistent jail as first step?
Since in this case only one line will be generated (jid), rc.d script
will be able to just take the output - this seems much less fragile
than the current method. Then of course it would proceed with jexec
running /etc/rc and in the end drop persist flag.

It looks like rc.d script still uses old syntax so this actually may be
less trivial than it sounds. That being said, if this is idea sounds
okay, I can try to come up with a patch this weekend.



There definitely is a difference between old and new jail behavior, not
just in the order of things:

glorfindel# jail -i -c name=foo command="foo"
5
jail: execvp: foo: No such file or directory

vs

glorfindel# /usr/obj`pwd`/jail -i -c name=foo command="foo"
jail: exec foo: No such file or directory
jail: foo: failed
-1

The jail id given back used to correspond to a jail that was created but
no longer exists by the time it's printed (or shortly thereafter). Now
it's a -1 indicating that no jail exists. I think the -1 is more
correct, but perhaps better for CURRENT but not STABLE? And the extra
"foo: failed" is printed by jail, as a generic message when a command
doesn't work out (for the case where the command itself doesn't print
a message).

Hmm ... I'll be pondering this one while I get a bite to eat :-).



Note that my proposal with persistent jail creation as first step doesn't
conflict with new behavior of jail(8) regarding jid printing.

Also, I think that head ->  tail change for rc.d script that I proposed is
broken.

I think that as a short-term solution you should restore old behavior
(jid printed before everything else) for -STABLE. The reason is that
currently you have to take the jid from the last line, but you cannot be
sure that jailed processes didn't mess with the output, so you actually
cannot trust the last line, so you don't know the actual jid.

That is:
rc.d/jail reads the last line

jail(8) just writes jid to very same file that contains output of jailed
/etc/rc. So if the last line written by jailed processes doesn't end with
newline character, jail(8) will just append jid to the line, so
the actual content of /var/run/jail_foo.id will consist of characters
written by possibly malicious script and jid.

This could be used to store jid of another jail (assuming jid 2, /etc/rc
consisting of echo -n 1 would result in stored jid 12 etc.) or random
content that in some conditions could lead to code execution.


I think I should restore the old behavior for CURRENT as well. The -i
option really only exists for /etc/rc.d/jail, and should behave the way
it expects it to. And if anything else uses it, all the more reason not
to change it.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Jail startup/shutdown broken on latest 9-STABLE

[Jamie Gritton]

On 05/24/12 16:30, Mateusz Guzik wrote:

On Thu, May 24, 2012 at 06:20:15PM -0400, Mike Jakubik wrote:

On Fri, 2012-05-25 at 00:13 +0200, Mateusz Guzik wrote:

On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote:

On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote:

On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote:

Hello,

Latest 9-STABLE has introduced some changes that break the ezjail rc
script. On bootup it fails to start, but when i log in via ssh and
manually start it, it works. However i am unable to shut them down
afterwards.


Try this:
http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch

cd /usr/src&&  patch -p1<  patch&&  cd usr.sbin/jail&&  make&&  make install

/usr/src/etc/rc.d/jail script can be just copied over.

Note that your /var/run/jail_* files have broken content (some line from
/etc/rc's output instead of jail id).



Mateusz,

Thanks for the patch, it fixes the startup issue on boot, however
shutting down the jails still does not work. The /var/run files have
garbage in them as you mentioned.

root@jail.local:~# cat /var/run/jail_app.id
/etc/rc: WARNING: $hostname is not set -- see rc.conf(5).


Hostname is set in /etc/rc.conf.


This message is about rc.conf from your jail.

This should be fixed by my change to etc/rc.d/jail, are you sure that
you are running patched version?



Right, i just realized this. I set the hostname in the jailed rc.conf,
now the file contains this:

root@jail.local:~# cat /var/run/jail_app.id
Setting hostname: app.local.

I do not see a link to your jail rc.d script, just the patch.




Patch contains two fixes, for both usr/sbin/jail and etc/rc.d/jail.

Assuming that the patch is still applied to your source tree, just do:
cp /usr/src/etc/rc.d/jail /etc/rc.d/jail

This fixes the jail script to actually store jail id instead of messages
from /etc/rc.

That is, you should be able to stop jails started by new etc/rc.d/jail
script.



I've fixed jail to print the jid first, so rc.d/jail doesn't need any
updating. Well in CURRENT at least - MFCing soon.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: The problem with starting/stopping of jail in the last 9-STABLE.

[Jamie Gritton]

On 05/31/12 07:56, Serg R wrote:

At system startup, a message:
Starting jails: cannot start jail "test":
  -1

# /etc/rc.d/jail start
Starts jail successfully.

# ee /var/run/jail_test.id
Setting hostname: test.

# /etc/rc.d/jail stop
Stopping jails: test

# jls
JID  IP Address  Hostname  Path
  3  10.2.8.7 test   
/usr/jails/www

#uname -a
FreeBSD sorgo 9.0-STABLE FreeBSD 9.0-STABLE #4: Thu May 31 13:39:39 SAMT 2012   
  root@sorgo:/usr/obj/usr/src/sys/SORGO  amd64


That's no longer the latest 9-STABLE - I MFCd some patches today that
should fix this.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: problem stoping jails with jail(8), jail.conf and mount.fstab

[Jamie Gritton]

On 02/12/13 07:47, Harald Schmalzbauer wrote:

  Hello,

on 9.1-R, I highly appreciate the new jail(8) and jail.conf
capabilities. Thanks for that extension!

But I have one problem: If I want to stop a jail with 'jaill -r
jailname', I get "umount: unmount of /.jail.jailname failed: Device busy"

It seems to me that the order of fstab.jailname entries are not reverted
by jail(8) when shutting down/umounting.
My C skills don't allow me to verify/fix that in usr.sbin/jail/command.c

Can anybody help please?

Thanks,

-Harry



Yes, that's a serious drawback.  I'll work something up for that.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: new jail(8) ignoring devfs_ruleset?

[Jamie Gritton]

On 02/15/13 09:27, Harald Schmalzbauer wrote:

  Hello,

like already posted, on 9.1-R, I highly appreciate the new jail(8) and
jail.conf capabilities. Thanks for that extension!

Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
   Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...

Thanks for any help,

-Harry


devfs_ruleset is only used along with mount.devfs - do you also have
that set in jail.conf?

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: new jail(8) ignoring devfs_ruleset?

[Jamie Gritton]

On 02/18/13 01:54, Harald Schmalzbauer wrote:

  schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):

On 02/15/13 09:27, Harald Schmalzbauer wrote:

   Hello,

like already posted, on 9.1-R, I highly appreciate the new jail(8) and
jail.conf capabilities. Thanks for that extension!

Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...

Thanks for any help,

-Harry


devfs_ruleset is only used along with mount.devfs - do you also have
that set in jail.conf?


Thanks for your response.

Yes, I have mount.devfs; set.
Otherwise I wouldn't have any device inside my jail. Verified - and like
intended, right?
Another notable discrepancy: The man page tells that devfs_rulset is "4"
by default.
But when I don't set devfs_rulset in jail.conf at all, inside the jail,
'sysctl security.jail.devfs_ruleset': 0
When set, like mentioned above, it returns the corresponding value, but
it doesn't have any effect.
How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like
to help finding the source, but have missed the whole new jail evolution...
Inside my jails, I don't have a fstab, outside I have them defined and
enabled with "mount" - and noticed the non-reverted umounting.


I found the problem - I noticed you mentioned 9.1-R, and took a look at
devfs(5). On CURRENT, there's a mount option "ruleset", that isn't there
on 9.

So I'll have to get around it by running devfs(8) after the mount. I'll
work on a patch for that.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: new jail(8) ignoring devfs_ruleset?

[Jamie Gritton]

On 02/18/13 09:29, Mateusz Guzik wrote:

On Mon, Feb 18, 2013 at 09:26:42AM -0700, Jamie Gritton wrote:

On 02/18/13 01:54, Harald Schmalzbauer wrote:

  schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):

On 02/15/13 09:27, Harald Schmalzbauer wrote:

   Hello,

like already posted, on 9.1-R, I highly appreciate the new jail(8) and
jail.conf capabilities. Thanks for that extension!

Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...

Thanks for any help,

-Harry


devfs_ruleset is only used along with mount.devfs - do you also have
that set in jail.conf?


Thanks for your response.

Yes, I have mount.devfs; set.
Otherwise I wouldn't have any device inside my jail. Verified - and like
intended, right?
Another notable discrepancy: The man page tells that devfs_rulset is "4"
by default.
But when I don't set devfs_rulset in jail.conf at all, inside the jail,
'sysctl security.jail.devfs_ruleset': 0
When set, like mentioned above, it returns the corresponding value, but
it doesn't have any effect.
How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like
to help finding the source, but have missed the whole new jail evolution...
Inside my jails, I don't have a fstab, outside I have them defined and
enabled with "mount" - and noticed the non-reverted umounting.


I found the problem - I noticed you mentioned 9.1-R, and took a look at
devfs(5). On CURRENT, there's a mount option "ruleset", that isn't there
on 9.

So I'll have to get around it by running devfs(8) after the mount. I'll
work on a patch for that.



Why not MFC support for that mount option instead?


That may be a better way around it, since either solution will require
an MFC. It'd be nice to have a patch to jail(8) anyway, since just
dropping in a new jail program is easier than dropping in a new kernel.

I'll have to take a look at the devfs code and see if that was a
reasonably small change.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: new jail(8) ignoring devfs_ruleset?

[Jamie Gritton]

On 02/18/13 09:29, Mateusz Guzik wrote:

On Mon, Feb 18, 2013 at 09:26:42AM -0700, Jamie Gritton wrote:

On 02/18/13 01:54, Harald Schmalzbauer wrote:

  schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):

On 02/15/13 09:27, Harald Schmalzbauer wrote:

   Hello,

like already posted, on 9.1-R, I highly appreciate the new jail(8) and
jail.conf capabilities. Thanks for that extension!

Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...

Thanks for any help,

-Harry


devfs_ruleset is only used along with mount.devfs - do you also have
that set in jail.conf?


Thanks for your response.

Yes, I have mount.devfs; set.
Otherwise I wouldn't have any device inside my jail. Verified - and like
intended, right?
Another notable discrepancy: The man page tells that devfs_rulset is "4"
by default.
But when I don't set devfs_rulset in jail.conf at all, inside the jail,
'sysctl security.jail.devfs_ruleset': 0
When set, like mentioned above, it returns the corresponding value, but
it doesn't have any effect.
How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like
to help finding the source, but have missed the whole new jail evolution...
Inside my jails, I don't have a fstab, outside I have them defined and
enabled with "mount" - and noticed the non-reverted umounting.


I found the problem - I noticed you mentioned 9.1-R, and took a look at
devfs(5). On CURRENT, there's a mount option "ruleset", that isn't there
on 9.

So I'll have to get around it by running devfs(8) after the mount. I'll
work on a patch for that.



Why not MFC support for that mount option instead?


I wasn't quite right about it not being in 9.1. I was looking at my 9.0
desktop, and it's not there. But it was in fact MFCd into 9.1. So I'm
back to saying as long as you use the devfs_ruleset parameter, your
jailed /dev should be correct.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: new jail(8) ignoring devfs_ruleset?

[Jamie Gritton]

On 03/21/13 17:59, Miroslav Lachman wrote:

Jeremie Le Hen wrote:

On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote:

schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):

On 02/15/13 09:27, Harald Schmalzbauer wrote:

Hello,

like already posted, on 9.1-R, I highly appreciate the new jail(8) and
jail.conf capabilities. Thanks for that extension!

Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...

Thanks for any help,

-Harry


devfs_ruleset is only used along with mount.devfs - do you also have
that set in jail.conf?


Thanks for your response.

Yes, I have mount.devfs; set.
Otherwise I wouldn't have any device inside my jail. Verified - and like
intended, right?
Another notable discrepancy: The man page tells that devfs_rulset is "4"
by default.
But when I don't set devfs_rulset in jail.conf at all, inside the jail,
'sysctl security.jail.devfs_ruleset': 0
When set, like mentioned above, it returns the corresponding value, but
it doesn't have any effect.
How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like
to help finding the source, but have missed the whole new jail
evolution...
Inside my jails, I don't have a fstab, outside I have them defined and
enabled with "mount" - and noticed the non-reverted umounting.


Look at what's in /dev from you jail. There should a few pseudo
devices (see below), but no real devices:

$ ls /dev
crypto log ptmx random stdin urandom zfs
fd null pts stderr stdout zero


I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC

I am now testing new jail.conf possibilities and I am seeing all devices
in /dev in jail.

Even if I set all this in my jail.conf

exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset = 4;
allow.set_hostname = false;

path = "/vol0/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";

## Jail bali
bali {
host.hostname = "bali.XXX.YY;
ip4.addr = xx.xx.xx.xx;
devfs_ruleset = 4;
}





# jexec 4 tcsh

root@bali:/ # ls -l /dev/
total 4
crw-r--r-- 1 root wheel 0, 35 Mar 1 19:39 acpi
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad10 -> ada3
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad10s1 -> ada3s1
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1a -> ada3s1a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1b -> ada3s1b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1d -> ada3s1d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1e -> ada3s1e
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1f -> ada3s1f
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1g -> ada3s1g
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad10s2 -> ada3s2
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2a -> ada3s2a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2b -> ada3s2b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2d -> ada3s2d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2e -> ada3s2e
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad4 -> ada0
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad6 -> ada1
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad8 -> ada2
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad8s1 -> ada2s1
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1a -> ada2s1a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1b -> ada2s1b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1d -> ada2s1d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1e -> ada2s1e
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1f -> ada2s1f
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1g -> ada2s1g
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad8s2 -> ada2s2
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2a -> ada2s2a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2b -> ada2s2b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2d -> ada2s2d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2e -> ada2s2e
crw-r- 1 root operator 0, 106 Mar 1 19:39 ada0
crw-r- 1 root operator 0, 108 Mar 1 19:39 ada1
crw-r- 1 root operator 0, 114 Mar 1 19:39 ada2
crw-r- 1 root operator 0, 120 Mar 1 19:39 ada2s1
crw-r- 1 root operator 0, 130 Mar 1 19:39 ada2s1a
crw-r- 1 root operator 0, 132 Mar 1 19:39 ada2s1b
crw-r- 1 root operator 0, 134 Mar 1 19:39 ada2s1d
crw-r- 1 root operator 0, 136 Mar 1 19:39 ada2s1e
crw-r- 1 root operator 0, 138 Mar 1 19:39 ada2s1f
crw-r- 1 root operator 0, 140 Mar 1 19:39 ada2s1g
crw-r- 1 root operator 0, 122 Mar 1 19:39 ada2s2
crw-r- 1 root operator 0, 142 Mar 1 19:39 ada2s2a
crw-r- 1 root operator 0, 144 Mar 1 19:39 ada2s2b
crw-r- 1 root operator 0, 146 Mar 1 19:39 ada2s2d
crw-r- 1 root operator 0, 148 Mar 1 19:39 ada2s2e
crw-r-

Re: new jail(8) ignoring devfs_ruleset?

[Jamie Gritton]

On 03/21/13 18:20, Miroslav Lachman wrote:

Jamie Gritton wrote:

On 03/21/13 17:59, Miroslav Lachman wrote:

Jeremie Le Hen wrote:

On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote:

schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):

On 02/15/13 09:27, Harald Schmalzbauer wrote:

Hello,

like already posted, on 9.1-R, I highly appreciate the new jail(8)
and
jail.conf capabilities. Thanks for that extension!

Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...


[...]


I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC

I am now testing new jail.conf possibilities and I am seeing all devices
in /dev in jail.

Even if I set all this in my jail.conf

exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset = 4;
allow.set_hostname = false;

path = "/vol0/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";

## Jail bali
bali {
host.hostname = "bali.XXX.YY;
ip4.addr = xx.xx.xx.xx;
devfs_ruleset = 4;
}


[...]


Is it a problem in my understanding of manpage / configuration, or is it
a bug in jail command on 9.1-RELEASE?


It's a bug (deficiency) in the jail command.


Is there a workaround or is it impossible to use jails with devfs on
FreeBSD 9.1?
Shouldn't it be mentioned in 9.1 errata?

Is it fixed in stable/9?

Thank you for your reply and your great work on new jails!


It's not fixed anywhere yet - it sometimes works in current, and
sometimes doesn't. I've been meaning to patch it up, but it the problem
is what I think it is, the patching up is a pretty big operation.

It doesn't mean you can't use jails with devfs in 9.1, just that you
can't use them with jail.conf. The old jail rc file that's all
shell-based is still the official jail startup method, and that one
still works. So existing systems will still work as expected, hence no
errata.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: new jail(8) ignoring devfs_ruleset?

[Jamie Gritton]

On 05/09/13 03:17, Jeremie Le Hen wrote:

On Thu, Mar 21, 2013 at 06:46:57PM -0600, Jamie Gritton wrote:


It's not fixed anywhere yet - it sometimes works in current, and
sometimes doesn't. I've been meaning to patch it up, but it the problem
is what I think it is, the patching up is a pretty big operation.

It doesn't mean you can't use jails with devfs in 9.1, just that you
can't use them with jail.conf. The old jail rc file that's all
shell-based is still the official jail startup method, and that one
still works. So existing systems will still work as expected, hence no
errata.


Shouldn't we warn the user about that in the manpage though?


Well really we ought to fix it. I guess the man page could have
something in the meantime, about an assumption that when you specify a
devfs ruleset, that the ruleset in question must actually exist at the time.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: new jail(8) ignoring devfs_ruleset?

[Jamie Gritton]

On 05/09/13 22:42, Dewayne Geraghty wrote:

An ugly workaround to complete the jail closure, when relying on jail.conf, is 
to:

jail -r $JAILNAME
umount /$LOCATION_OF_JAILS/$JAILNAME/dev || true


The only problem with devfs I'm aware of is it not catching the right
ruleset when starting in the rc system. So does this mean you're having
problems unmounting /dev?

What happens when you add a "-v" to the "jail -r"? It should note that
/dev is being umounted.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: regression with jexec?

[Jamie Gritton]

Michael Butler wrote:


After a clean rebuild ('rm -rf /usr/obj/*') ..

i...@aaron:/home/imb> uname -a
FreeBSD aaron.protected-networks.net 7.2-STABLE FreeBSD 7.2-STABLE #0:
Sat Jul 25 05:39:55 EDT 2009

i...@aaron:/home/imb> jls
   JID  IP Address  Hostname  Path

 [ .. ]

 5  202.12.127.68   db.protected-networks.net
/usr/local/jails/db.protected-networks.net

i...@aaron:/home/imb> sudo jexec 5 tcsh
jexec: Unable to parse jail ID.: No such file or directory

Huh?

imb



The symptom in jexec can be fixed by this little patch:

Index: usr.sbin/jexec/jexec.c
===
--- usr.sbin/jexec/jexec.c  (revision 195879)
+++ usr.sbin/jexec/jexec.c  (working copy)
@@ -248,6 +248,7 @@
if (argc < 2)
usage();
if (strlen(argv[0]) > 0) {
+   errno = 0;
jid = (int)strtol(argv[0], NULL, 10);
if (errno)
err(1, "Unable to parse jail ID.");

But the broader problem is malloc.  It's leaving errno set to
ENOENT when /etc/malloc.conf doesn't exist.  This seems like
wrong behavior to me.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: regression with jexec?

[Jamie Gritton]

Bjoern A. Zeeb wrote:

On Sun, 26 Jul 2009, Kostik Belousov wrote:


On Sat, Jul 25, 2009 at 09:06:34PM -0400, Michael Butler wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jamie Gritton wrote:

Michael Butler wrote:

i...@aaron:/home/imb> sudo jexec 5 tcsh
jexec: Unable to parse jail ID.: No such file or directory




The symptom in jexec can be fixed by this little patch:

Index: usr.sbin/jexec/jexec.c
===
--- usr.sbin/jexec/jexec.c(revision 195879)
+++ usr.sbin/jexec/jexec.c(working copy)
@@ -248,6 +248,7 @@
 if (argc < 2)
 usage();
 if (strlen(argv[0]) > 0) {
+errno = 0;
 jid = (int)strtol(argv[0], NULL, 10);
 if (errno)
 err(1, "Unable to parse jail ID.");


Thanks - this certainly cures the effect.


But the broader problem is malloc.  It's leaving errno set to
ENOENT when /etc/malloc.conf doesn't exist.  This seems like
wrong behavior to me.


Seems like a POLA violation to me,


No, this is how errno generally work, it is not changed if no error
happens.


I haven't really understood which part, when and why would set the errno in
first place so that it would still be there?  Is it something in jexec
that gets the errno in first place or is it something internal to
malloc that sets it returns successfully and doesn't clear it?


The POLA violation is in malloc - it sets errno even when there was no
error.  The allocation succeeded and a pointer was returned, yet errno
was set to ENOENT (not even an error malloc should be able to return).
The fact that malloc looks for an optional config file and doesn't find
one shouldn't be relayed back to the caller in errno.  If
/etc/malloc.conf doesn't exist, it should either clear errno after that,
or perhaps restore its previous value.  There's also a
getenv("MALLOC_OPTIONS") that can similarly set errno.

Perhaps this has all been gone over before and I missed it (this is from
code that's been stable since 2006), so I wouldn't want to just rush in
and fix malloc.  Maybe this general principle has already been discussed
and my viewpoint lost.  But if not, it's my opinion that malloc is
acting badly and needs a change.

In the meantime, I have no problem with errno not being cleared in
strtol, and the patch to jexec is correct (though strictly speaking it
shouldn't be necessary since we "know" errno has not yet been set).

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: regression with jexec?

[Jamie Gritton]

Kostik Belousov wrote:

On Sun, Jul 26, 2009 at 08:28:05AM -0600, Jamie Gritton wrote:

Bjoern A. Zeeb wrote:

On Sun, 26 Jul 2009, Kostik Belousov wrote:


On Sat, Jul 25, 2009 at 09:06:34PM -0400, Michael Butler wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jamie Gritton wrote:

Michael Butler wrote:

i...@aaron:/home/imb> sudo jexec 5 tcsh
jexec: Unable to parse jail ID.: No such file or directory

The symptom in jexec can be fixed by this little patch:

Index: usr.sbin/jexec/jexec.c
===
--- usr.sbin/jexec/jexec.c(revision 195879)
+++ usr.sbin/jexec/jexec.c(working copy)
@@ -248,6 +248,7 @@
if (argc < 2)
usage();
if (strlen(argv[0]) > 0) {
+errno = 0;
jid = (int)strtol(argv[0], NULL, 10);
if (errno)
err(1, "Unable to parse jail ID.");

Thanks - this certainly cures the effect.


But the broader problem is malloc.  It's leaving errno set to
ENOENT when /etc/malloc.conf doesn't exist.  This seems like
wrong behavior to me.

Seems like a POLA violation to me,

No, this is how errno generally work, it is not changed if no error
happens.

I haven't really understood which part, when and why would set the errno in
first place so that it would still be there?  Is it something in jexec
that gets the errno in first place or is it something internal to
malloc that sets it returns successfully and doesn't clear it?

The POLA violation is in malloc - it sets errno even when there was no
error.  The allocation succeeded and a pointer was returned, yet errno
was set to ENOENT (not even an error malloc should be able to return).
The fact that malloc looks for an optional config file and doesn't find
one shouldn't be relayed back to the caller in errno.  If
/etc/malloc.conf doesn't exist, it should either clear errno after that,
or perhaps restore its previous value.  There's also a
getenv("MALLOC_OPTIONS") that can similarly set errno.

Perhaps this has all been gone over before and I missed it (this is from
code that's been stable since 2006), so I wouldn't want to just rush in
and fix malloc.  Maybe this general principle has already been discussed
and my viewpoint lost.  But if not, it's my opinion that malloc is
acting badly and needs a change.

In the meantime, I have no problem with errno not being cleared in
strtol, and the patch to jexec is correct (though strictly speaking it
shouldn't be necessary since we "know" errno has not yet been set).

Let me restate that errno is never cleared when no error occured.
It is only set when error took place.

E.g., for syscalls, you should look into errno only if syscall returned
-1, in most cases.

For non-syscall libc functions, you need to clear errno before the call,
then check for the error return (for strtoul that would be ULONG_MAX
or 0), that seems to be missed from your patch, and only then look for
errno.

See RETURN VALUES section of the strtoul(3).


All true - and I'll add the check you mention to my patch.

But what about the malloc case?  Is it equally valid to say that errno
should not be set when no error occurred?  Or are non-syscall libc
functions generally given free reign to overwrite errno in non-error
situations?

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: regression with jexec?

[Jamie Gritton]

Kostik Belousov wrote:

On Sun, Jul 26, 2009 at 08:50:15AM -0600, Jamie Gritton wrote:

All true - and I'll add the check you mention to my patch.

But what about the malloc case?  Is it equally valid to say that errno
should not be set when no error occurred?  Or are non-syscall libc
functions generally given free reign to overwrite errno in non-error
situations?


Yes, they have a blanket to override errno when no error is returned to
the caller. Malloc is good example.

Errno is defined only after error.


OK then, patching jexec is all that needs doing;  I'll get that in.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?)

[Jamie Gritton]

Marcel Moolenaar wrote:

All,

I just got this overnight on my server:

Fatal trap 12: page fault while in kernel mode
fault virtual address= 0x90
fault code= supervisor read, page not present
instruction pointer= 0x20:0xc05ba39d
stack pointer= 0x28:0xf31077bc
frame pointer= 0x28:0xf31077c8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process= 928 (NLM: master)

(kgdb) bt
#0  doadump () at pcpu.h:246
#1  0xc05e03f3 in boot (howto=260) at 
/zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_shutdown.c:416

#2  0xc05e062d in panic (fmt=Variable "fmt" is not available.
) at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_shutdown.c:579
#3  0xc04ac807 in db_panic (addr=Could not find the frame base for 
"db_panic".

) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:478
#4  0xc04acd91 in db_command (last_cmdp=0xc0881c3c, cmd_table=0x0, 
dopager=1) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:445
#5  0xc04aceea in db_command_loop () at 
/zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:498
#6  0xc04aed5d in db_trap (type=12, code=0) at 
/zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_main.c:229
#7  0xc0608a14 in kdb_trap (type=12, code=0, tf=0xf310777c) at 
/zmirror/nfs/freebsd/base/stable/8/sys/kern/subr_kdb.c:535
#8  0xc07c53af in trap_fatal (frame=0xf310777c, eva=144) at 
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:924
#9  0xc07c5650 in trap_pfault (frame=0xf310777c, usermode=0, eva=144) at 
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:846
#10 0xc07c5ff2 in trap (frame=0xf310777c) at 
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:528
#11 0xc07ac50b in calltrap () at 
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/exception.s:165
#12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at 
/zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568
#13 0xc05d39ee in priv_check_cred (cred=0xc61e4880, priv=334, flags=0) 
at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_priv.c:92
#14 0xc09dbffc in secpolicy_fs_owner (mp=0xc4112284, cred=0xc61e4880) at 
/zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_policy.c:86 

#15 0xc09dc527 in secpolicy_vnode_access (cred=0xc61e4880, 
vp=0xc4bb6d9c, owner=501, accmode=128)
at 
/zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_policy.c:125 

#16 0xc0a56c5c in zfs_zaccess (zp=0xd4be8658, mode=2, flags=Variable 
"flags" is not available.
) at 
/zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2445 

#17 0xc0a56edb in zfs_zaccess_rwx (zp=0xd4be8658, mode=Variable "mode" 
is not available.
) at 
/zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2484 

#18 0xc0a6bfa4 in zfs_freebsd_access (ap=0xf31078d4) at 
/zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1068 

#19 0xc07cfeb2 in VOP_ACCESS_APV (vop=0xc0acfac0, a=0xf31078d4) at 
vnode_if.c:571

#20 0xc0718c93 in nlm_get_vfs_state (host=Variable "host" is not available.
) at vnode_if.h:254
#21 0xc0718e30 in nlm_do_unlock (argp=0xf31079c8, result=0xf3107a08, 
rqstp=0xcb199800, rpcp=0x0) at 
/zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_impl.c:2227
#22 0xc071ac87 in nlm4_unlock_4_svc (argp=0xf31079c8, result=0xf3107a08, 
rqstp=0xcb199800) at 
/zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_server.c:540
#23 0xc071bce3 in nlm_prog_4 (rqstp=0xcb199800, transp=0xc652de00) at 
/zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_svc.c:512
#24 0xc07284bf in svc_run_internal (pool=0xc61e4c80, ismaster=1) at 
/zmirror/nfs/freebsd/base/stable/8/sys/rpc/svc.c:893
#25 0xc072943d in svc_run (pool=0xc61e4c80) at 
/zmirror/nfs/freebsd/base/stable/8/sys/rpc/svc.c:1233
#26 0xc071a348 in nlm_syscall (td=0xc6551000, uap=0xf3107cf8) at 
/zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_impl.c:1593
#27 0xc07c5977 in syscall (frame=0xf3107d38) at 
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:1073
#28 0xc07ac570 in Xint0x80_syscall () at 
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/exception.s:261

#29 0x0033 in ?? ()

(kgdb) frame 12
#12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at 
/zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568

3568switch (priv) {
(kgdb) l 3567
3562 */
3563if (cred->cr_prison->pr_flags & PR_VNET)
3564return (0);
3565}
3566#endif /* VIMAGE */
3567   
3568switch (priv) {
3569   
3570/*

3571 * Allow ktrace privileges for root in jail.
(kgdb) p cred->cr_prison
$4 = (struct prison *) 0x0


It seems to be NFS related.  I think the null pointer in question is
from the expor

Re: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?)

[Jamie Gritton]

Rick Macklem wrote:

On Sun, 27 Sep 2009, Robert Watson wrote:

On Fri, 25 Sep 2009, Jamie Gritton wrote:

It seems to be NFS related.  I think the null pointer in question is 
from the export's anonymous credential.  Try the patch below and see 
if it helps (which I guess means run it overnight and see if it 
crashes again).  I've also patched a similar missing cred prison in 
GSS_SVC, since I'm not versed enough in NFS/RPC stuff to know if it 
might be the problem.


This is one of the reasons I really dislike "magic" credentials and 
special handling of NULL credentials -- they always get into code the 
author doesn't expect, and either there are bad pointer dereferences, 
or incorrect security decisions.  It's almost always the case that a 
correct credential should have been cached or generated at some 
earlier point to represent the security context...



I don't really understand prisons/jails, but would creating these
credentials via:
crdup(td->td_ucred); // duplicating the daemon thread's cred
- and then replacing the 
make sense as an alternative to starting with crget()?
(ie. All the other stuff except  would be "inherited" from the
credential for the daemon thread.)


That sounds right to me for cases when the cred is based on passed
UID/GIDs. Perhaps you'd want to use the UID-changing helper functions on
kern_prot.c, or perhaps a new helper or helpers just for the circumstance.

- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"