jailkit - jailed user unable to connect.

English Install/Boot/Login
1

Hello.
I try to chroot a user using jailkit.

The jail path is /home/jail
The user name is fan_speed and belongs to standard group users
After creation the user home is transferred from /home/fan_speed to /home/jail/home/fan_speed using jailkit script

jk_jailuser -m -j /home/jail/fan_speed

The new home path for the jailed user is /home/jail/home/fan_speed

/etc/passwd show :

fan_speed:x:1004:100:LOGON USER in JAIL:/home/jail/./home/fan_speed:/usr/sbin/jk_chrootsh

/home/jail/etc/passwd show :

fan_speed:x:1004:100:LOGON USER in JAIL:/home/jail/./home/fan_speed:/usr/sbin/jk_lsh

/var/log/messages show :

§TIME§ Aug 27 00:01:05,§PR§ 6,§FCLTY§ 10,§HOST§ LINUX-TEST-123, §TAG§  kdm:, §MSG§  { :0[13711]: pam_unix(xdm:session): session opened for user fan_speed by (uid=0)} 

§TIME§ Aug 27 00:01:05,§PR§ 6,§FCLTY§ 4,§HOST§ LINUX-TEST-123, §TAG§  systemd-logind[836]:, §MSG§  { New session 61 of user fan_speed.} 

§TIME§ Aug 27 00:01:05,§PR§ 6,§FCLTY§ 4,§HOST§ LINUX-TEST-123, §TAG§  systemd-logind[836]:, §MSG§  { Linked /tmp/.X11-unix/X0 to /run/user/1004/X11-display.} 

§TIME§ Aug 27 00:01:05,§PR§ 3,§FCLTY§ 4,§HOST§ LINUX-TEST-123, §TAG§  jk_chrootsh[14800]:, §MSG§  { abort, homedir '/home/jail/home/fan_speed' for user fan_speed (1004) does not contain the jail separator <jail>/./<home>} 

§TIME§ Aug 27 00:01:05,§PR§ 6,§FCLTY§ 10,§HOST§ LINUX-TEST-123, §TAG§  kdm:, §MSG§  { :0[13711]: pam_unix(xdm:session): session closed for user fan_speed} 

§TIME§ Aug 27 00:01:05,§PR§ 6,§FCLTY§ 4,§HOST§ LINUX-TEST-123, §TAG§  systemd-logind[836]:, §MSG§  { Removed session 61.}

Any help is welcome.

2

First,
I’ve never heard of jailkit.
When you post about using an app like this, you need to describe where you got it from, ie an openSUSE repossitory, from source, from some website, etc. and of course, if there are versions you likely need to state the version.

Aside from that, I don’t know what your objectives are in chrooting, but nowadays there are “better” alternatives to chroot. Original chroot is OK for quickly configuring something fairly simple without regard for security but if you want “better” security chroot is very lacking… So there are recipes for locking down what is missing.

Or, typically you can choose something else which is fundamentally more secure but still based on the idea of isolating similar to how chroot works. For your consideration

LXC - Simple to setup using YAST. Just install LXC and the YAST LXC applet. You may want to configure Linux Bridge Devices for networking, you can do that in YAST to create a simple bridge or Libvirt to create networks that support NAT and DHCP easily.

systemd-nspawn - Just install the package and run it. Read the MAN pages to configure. This gives you vastly better security by default compared to chroot and is very simple to setup and run (generally).

docker - This is still a bit on the leading/bleeding edge, current technology is less than 8 months old as of this writing. Is still based on long standing solid techniques of namespaces and cgroups but some things like User Account (non-root) permissions are still being worked on.

In fact, the whole general usage of securing by individual non-root User accounts is supposedly a bit questionable at the moment no matter what chroot or container technology you use… Proper security supposedly waiting for namespaces to be applied to kernel processes before security can be considered realistic.

So, the big question is what you intend to do with your chroot. If you just want to keep trusted Users honest, then current chroot and containers are OK but if you might be exposing to unknown or questionable Users, then you should probably wait until new improvements which are just around the corner (estimated within the next 6 mths I hear). Current recommended use for Chrooting and containers is to deploy a Server service, not a file system environment for Users to login and use.

BTW - You might briefly skim what I wrote about setting up a chroot, ignore the parts about OpenStack (I ran into issues which couldn’t be resolved at the time I wrote the article). It doesn’t attempt to address what you asked about (User permissions) but shows how you can setup a chroot or systemd-nspawn without scripts.
http://en.opensuse.org/User:Tsu2/chroot-nspawn-OpenStack#systemd-nspawn

You might be interested in the announcement for Docker 1.2 (which is available already in the Virtualization repo) which was announced only about 3 days ago, the “cap-add” and “cap-drop” sections apply to setting permissions within the container
https://blog.docker.com/2014/08/announcing-docker-1-2-0/

TSU

3

BTW - Without more information, I’d hazard a wild guess that your User permissions problem is a violation of an SElinux MAC.

TSU

4

I found it while I was googleing : Jailkit - chroot jail utilities

I have to solve a problem posed by nvidia driver (Especially in reason including the way nvidia engineers think instead of their client) .
I must pass command to the driver as soon as my server is powered up. You cannot pass command to the driver if you don’t have an X session opened. And on a server generally no body is logged all day long.
So I have created a specific user and this user is automatically log on as the server is started.

For the moment, I have solve part of my problem by assigning it “/usr/bin/rbash” as login shell.

5

If you want to set it up “the systemd way”
Information about configuring a service to “run as user”
https://bbs.archlinux.org/viewtopic.php?id=162297
Recommend that this user be set up as a non-interactive user (easy to do in YAST)

The above bbs discussion thread describes the structure and commands you want to place in your Unit file, which should be placed somewhere in

/etc/systemd/system/multi-user.target.wants/

“multi-user.target” should be the environment your system boots to and will stay if there is no GUI Desktop environment running. You can store your Unit file in this location where other “want” services are stored and wire up the dependency in the Unit file so that your script is invoked along with the others at this boot stage.

I don’t know that you should need to chroot your command, at first blush I’d guess that simply invoking as a system service should be sufficiently secure, particularly if you run the script with the security context of a non-interactive User with limited (ie ordinary User if not restricted further) permissions. Naturally, make sure your file permissions are sufficient for your chosen User account.

It looks like jailkit is one of many solutions to address the default security issues using chroot. Is OK, but as I noted sometime soon if not already basic chroot may become less used as new alternatives mature.

TSU

6

As I said , the call to the nvidia driver is only possible If the caller own an X session (or X Display). If not, you got an “No X Display error”

So ?

7

Right, Overlooked.

Would need testing, I’d consider

  1. Try hooking into “graphical.target” instead so the User has a graphical environment.
    This is an unusual scenario, so would need some testing I’d guess the main OS has to also be installed to boot into at least a MinX environment
  2. Maybe you don’t need to boot into a graphical environment. Maybe all you need to do is start an xserver and invoke xscreen with fluxbox for your command.

It’s been many years since I did the second option above(and it was run with a running xserver) and don’t work with this regularly so I don’t remember the details,only the general results.

TSU

8

Thank you for your help.
But the thread was about jailkit. In case of somebody knews it.

For the reason, why I plan to use chroot, or any restricted similar manner, you can read : https://forums.opensuse.org/showthread.php/500583-How-to-create-a-standard-user-with-limited-rights

9

I followed that thread for a bit, but saw no specific reason to chroot. Chroot is for when you want/need to run an isolated environment, most basically something that requires its own file system (hence, the “change root”).

Chrooting has nothing to do (at least IMO) with

  • running a service
  • running an alternative graphical environment
  • running anything in any kind of special security context

So, I’m mystified why you would want to chroot at all.

But, if you did there is <one> general purpose reason I can think of… To “package” a particular solution in an independent, portable way. And, there are many ways to do that, chroot is only one but should be if you are familiar with it. Otherwise, there are probably many simpler(more automatic) ways.

Other possible alternatives:

  • I mentioned the xscreen with fluxbox option in my previous post. IMO it’s probably the most lightweight approach if that is an objective.
  • Any kind of virtualization will probably work. Just install something like Virtualbox, set up your command and invoke by command line as soon as possible during bootup. BTW - I assume that since this is simply for monitoring and managing your fan that when this functionality is invoked is irrelevant.
  • Although very new, Docker (Linux Containers) is a “chroot on steroids” approach. Although you wouldn’t need the common reasons why Containers are used, you’d benefit from easy setup, packaging and deployment. But, you’d still need to build your image, likely again setting up xscreen and fluxbox.

But, you could also continue to use jailkit. But recognize that setting up a chroot is a part of your solution that isn’t central to your objective(in fact can be considered unnecessary) which is to deploy an alternative graphical environment and execute a command within that environment.

BTW - Did you take a close look at the Archlinux BBS link I gave you? Seemed to me the thread was about trying to setup exactly what you want which is a way to access the nVidia control panel which requires a graphical environment.

TSU