Segmentation Fault 11

R

redsmeg68

hi,

When I run a command inside a a jail using sudo I get a segmentation fault but running the command normally works.

How do I go about trouble shooting this ?
 
Hi,

Sudo(1) is just a wrapper, so you should first eliminate it by starting a shell with the credentials normally imparted by sudo. Make sure that the issue is repeatable in that context.

You then need to run the errant command under a debugger, probably lldb(1) for any recent binary.

I would get the source code, re-compile the application with "-O0 -g", and if you still get SIGSEGV.

Providing you are not dealing with an optimisation bug, It should be a lot easier to trace in that context.
 
redsmeg68 said:
the command works if I don't use sudo but seg faults if I do.
Click to expand...
We would have to know what's in the sudoers(5) file to be completely sure of how to proceed.

However, it's probably sufficient to investigate the following four scenarios of running the "command". We know that 1 works, and 2 produces SIGSEGV. Do you get SIGSEGV for cases 3 and 4:
Code: 
1.  command
2.  sudo command
3.  sudo /bin/sh
    command
    exit
4.  su
    command
    exit
Is there a core file produced in the current working directory when you get SIGSEGV? What is its name? We expect "*.core" where "*" is the name of the binary executable that received SIGSEGV.
 
gpw928 said:
We would have to know what's in the sudoers(5) file to be completely sure of how to proceed.

However, it's probably sufficient to investigate the following four scenarios of running the "command". We know that 1 works, and 2 produces SIGSEGV. Do you get SIGSEGV for cases 3 and 4:
Code: 
1.  command
2.  sudo command
3.  sudo /bin/sh
    command
    exit
4.  su
    command
    exit
Is there a core file produced in the current working directory when you get SIGSEGV? What is its name? We expect "*.core" where "*" is the name of the binary executable that received SIGSEGV.
Click to expand...


Hi sorry for the delay the problem went away After I completed an upgrade to Freebsd 12, and then it came back today.

I'm running the commands inside a jail. here are the steps

1.

m@phantom:~ % sudo jexec -U root 1

root@phantom / # hostname

phantom.xyz.com

root@phantom / # pwd

/

root@phantom / # sudo pwd

Segmentation fault: 11

root@phantom / # sudo /bin/sh

Segmentation fault: 11

root@phantom / # su

root@phantom ~ # pwd

/root

root@phantom ~ # exit

logout

root@phantom / #


There are no core files generated.
 
gpw928 said:
We would have to know what's in the sudoers(5) file to be completely sure of how to proceed.

However, it's probably sufficient to investigate the following four scenarios of running the "command". We know that 1 works, and 2 produces SIGSEGV. Do you get SIGSEGV for cases 3 and 4:
Code: 
1.  command
2.  sudo command
3.  sudo /bin/sh
    command
    exit
4.  su
    command
    exit
Is there a core file produced in the current working directory when you get SIGSEGV? What is its name? We expect "*.core" where "*" is the name of the binary executable that received SIGSEGV.
Click to expand...

sudoers contains the following

root ALL=(ALL) ALL
%admins ALL=(ALL) ALL
 
Running inside a jail makes a significant difference.

I'm not particularly competent with jails, and so should defer to somebody who is.

Please confirm that the problem only occurs inside the jail. Do you have more than one jail? Does it happen in any other jail?

What do you see if you list the dynamic dependencies of the sudo command both inside and outside the jail:
Code: 
ldd /usr/local/bin/sudo
.
Try running truss on the sudo command and save the output using a Bourne shell:
Code: 
truss sudo  pwd >/tmp/trace 2>&1
Compare the output to the same thing outside the jail.
 
It may happen if the command you are running in the jail requires some permissions that are by default forbidden in the jail. For example, the program may need to access files in /dev, which are hidden in the jails via /etc/defaults/devfs.rules. In this case, you need to check which devices are required for the program and unhide them in that file, then tell the jail which ruleset number in devfs.rules you want to be applied.
 
Side note: Why do you want to use sudo if you are connecting to jail already as root ?

To trace the problem, as gpw928 stated: provide ldd and truss output.
To get the core file make sure limits are set properly. Once you jexec to the jail set ulimit -c unlimited. Try sudo again. Check for core file.

I actually miss the segmentation error in syslog that Linux provides (you can see what address caused the segmentation fault and where).
 
_martin said:
Side note: Why do you want to use sudo if you are connecting to jail already as root ?

To trace the problem, as gpw928 stated: provide ldd and truss output.
To get the core file make sure limits are set properly. Once you jexec to the jail set ulimit -c unlimited. Try sudo again. Check for core file.

I actually miss the segmentation error in syslog that Linux provides (you can see what address caused the segmentation fault and where).
Click to expand...

Not all of the users login as root and so they need sudo.
 
gpw928 said:
Running inside a jail makes a significant difference.

I'm not particularly competent with jails, and so should defer to somebody who is.

Please confirm that the problem only occurs inside the jail. Do you have more than one jail? Does it happen in any other jail?

What do you see if you list the dynamic dependencies of the sudo command both inside and outside the jail:
Code: 
ldd /usr/local/bin/sudo
.
Try running truss on the sudo command and save the output using a Bourne shell:
Code: 
truss sudo  pwd >/tmp/trace 2>&1
Compare the output to the same thing outside the jail.
Click to expand...

Only 1 jail
Only happens in the Jail

The weird thing is that some days it just works fine and others it doesn't. The system is on a DigitalOcean droplet

Today its working so I have to wait for it to stop working again before I can get the answers on the last two
 
While waiting for the condition which triggers segfault how are your jails setup ? e.g. I still use sysutils/ezjail but had to manually adjust for 11.x version of jail. All jails share the same basejail which is basically mini-installation of FreeBSD base.
How does your /etc/jail.conf look like ? Did you modify any other files in /etc/when setting up these jails ?
 
You must log in or register to reply here.
Back
Top