Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On Raspbian, the Debian distro aimed at RPi, I end up getting the following error:

$ sudo su -l root -c /bin/bash
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

... however, if I change this to sudo su -, everything works fine. Any ideas what's wrong in the above command line? The main issue here is that the terminal is borked after this command ...

I found this bug report but it looks like there is no clonclusion.

System info

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 7.0 (wheezy)
Release:        7.0
Codename:       wheezy
$ dpkg -l |grep sudo
ii  libgksu2-0                            2.0.13~pre1-6                        armhf        library providing su and sudo functionality
ii  sudo                                  1.8.5p2-1                            armhf        Provide limited super user privileges to specific users


The reason I am using -c /bin/bash is that it actually looks more like -c /bin/bash --rcfile /path/to/rcfile ... and therefore is different from a mere sudo -i or sudo su - and so on ...

The reason I gave the command line as I did above in my question was that it is the minimal example that reproduces the problem.

share|improve this question
What is your aim in doing sudo su -l root -c /bin/bash? That is an extremely convoluted way of getting a root shell... – Chris Down Feb 23 '13 at 5:57
Looks like this is a legit regression from a security fix that wheezy will release with. – jordanm Feb 23 '13 at 6:15
What's all this -l root -c /bin/bash stuff? Why not just do this sudo su -? If the problem is that root's default shell is not bash, then why not change root's default shell to bash? – Red Cricket Feb 23 '13 at 6:45
There are parameters such as --rcfile past the /bin/bash. But they aren't relevant to reproduce the issue. What I produced here is a minimal working example to reproduce the bug. Without the -c part and everything following, this error doesn't occur. This is why this "convoluted" way ... – 0xC0000022L Feb 23 '13 at 16:54
@jordanm You were right. I'm getting this error just by doing su user - and I couldn't find a way around it. To make things worse, a ^C in the console will terminate it! If I open another bash from it and hit ^C, the console will randomly alternate between the root and the user console, so typing a command will send some letters to one console an other letters to the other. WTF? I can't find any work-arounds for this problem. (edit: Debian Wheezy, LXTerminal, user doing the su is root) – f.ardelian May 12 '13 at 22:23

After a bit of digging, it seems that this is expected behavior for now, because it's a security fix. On the other hand, I've discovered that it also adds a small security risk, but I'll have to do some more digging to make sure I'm not mistaking before reporting it to the Debian guys.

Here is the bug they fixed: login: tty hijacking possible in "su" via TIOCSTI ioctl

My understanding is that the su command used to leave /dev/tty open for the called process and so the process, even with lowered privileges could inject code in the terminal that would be executed after the su command ended. They patched it (I would say monkey-patched it) by closing the tty, which is why the newly started bash is complaining.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.