Hello, Jailkit is a tool for easy creation of chrooted-environments. Jailkit comes with scripts for creating users in chroot-environments. There are many predefined setups you can use to initialise the chroot-environment. See website for proper explanation of all the commands. Suggested portage location: app-admin/jailkit. It is an administration tool and its scripts are installed in /usr/sbin. Attachments: - The ebuild - A diff file - The licence file (extracted from the source package) Cheers, geta
Created attachment 37583 [details] jailkit-1.1.ebuild
Created attachment 37584 [details] jailkit-1.1-makefile.diff (patch for a makefile)
Created attachment 37585 [details] jailkit-licence.txt from the original source package (ther the file is called COPYRIGHT)
Can you change the ebuild to be text/plain so we can look at it?
changed ebuild mime type to text/plain
Created attachment 54615 [details] ebuild for jailkit-1.2 No changes were made to the ebuild itself (just a version bump). Please note that makefile-patch from 1.1 is used. Installation works on my system, however, there is a QA output during installation: QA Notice: /usr/sbin/jk_chrootsh is setXid, dynamically linked and using lazy bindings. This combination is generally discouraged. Try: CFLAGS='-Wl,-z,now' emerge jailkit
Created attachment 59066 [details] jailkit-1.3.ebuild ebuild for new version of jailkit. One notice in the changelog: - fixes some issues with Gentoo Linux This allowed me to reduce the complexity of the ebuild drastically. New ebuild requires a small patch to Makefile - sandboxing issue with /etc/shells. QA notice does still appear.
Created attachment 59067 [details] jailkit-1.3-Makefile.diff (patch for Makefile.in)
Created attachment 59577 [details] jailkit-1.3-r1.ebuild This revised version fixes a small issue with baselayout >= 1.11.x (which is still masked as unstable) The original initscript doesn't work anymore (when adding jailkit to a runlevel), so the ebuild now replaces it with a gentoo-initscript. Please give me feedback if this works with baselayout 1.9.x.
Created attachment 59578 [details] The jailkit initscript (for jk_socketd) and here is the initscript
Ok, here's some additional information for anyone wanting to try out this ebuild: - Make a new directory in your portage overlay (say /usr/local/portage/app-admin/jailkit). See http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=5#doc_chap2 on how to work with overlays - copy the ebuild into that directory - make a subdirectory called files. Place any auxiliary files in that directory (except the licence file). - Place the licence file (calling it "jailkit") into the directory /usr/local/portage/licenses - go back to /usr/local/portage/app-admin/jailkit and run "ebuild jailkit-VERSION.ebuild digest". Replace VERSION by the current version to be found in this bug report. - run "emerge -av jailkit"
after successfull emerge when i want to start jk_init foo jailkit # jk_init bash: /usr/sbin/jk_init: /usr/lib/portage/pym: bad interpreter: Permission denied
Thanks for reporting. Time for me to hack the ebuild. The "bad interpreter" error is down to two factors. I've singled them out from the compile process: 1. checking for python... /usr/lib/portage/pym. This path is correct within the sandbox portage uses to compile, but not when the python scripts have been moved to the live filesystem 2. make[1]: Entering directory `/var/tmp/portage/jailkit-1.3-r1/work/jailkit-1.3/py' python -c "import py_compile;py_compile.compile('jk_lib.py')" sed -e "s!LIBDIR='[a-z/]*'!LIBDIR='/var/tmp/portage/jailkit-1.3-r1/image//usr/share/jailkit'!" -e "s:#!/usr/bin/python:#!/usr/lib/portage/pym:" < jk_cp.in > jk_cp sed -e "s!LIBDIR='[a-z/]*'!LIBDIR='/var/tmp/portage/jailkit-1.3-r1/image//usr/share/jailkit'!" -e "s:#!/usr/bin/python:#!/usr/lib/portage/pym:" < jk_init.in > jk_init sed -e "s!LIBDIR='[a-z/]*'!LIBDIR='/var/tmp/portage/jailkit-1.3-r1/image//usr/share/jailkit'!" -e "s:#!/usr/bin/python:#!/usr/lib/portage/pym:" < jk_check.in > jk_check sed -e "s!LIBDIR='[a-z/]*'!LIBDIR='/var/tmp/portage/jailkit-1.3-r1/image//usr/share/jailkit'!" -e "s:#!/usr/bin/python:#!/usr/lib/portage/pym:" < jk_addjailuser.in > jk_addjailuser This is part of the make process for jailkit. So the "wrong" path found by autoconf then obviously ends up in /usr/sbin/jk_init on your system. Bear with me for a while and I'll post an updated (and more thoroughly tested) ebuild to this bug.
Created attachment 64880 [details] Patch for the python-scripts in jailkit This patch fixes an error resulting from the sandboxed "make" in emerge
Created attachment 64881 [details] jailkit-1.3-r2.ebuild
thanks for the good work, working really nice now
Created attachment 67288 [details] jailkit-1.3-r2.ebuild Tidied up the comments (shorter and clearer). Changed licence to BSD. Nothing fundamentally new, so no new version number. To install jailkit: - Make a new directory in your portage overlay. example: usr/local/portage/app-admin/jailkit. See http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=5#doc_chap2 on how to work with overlays. - copy the ebuild into that directory - make a subdirectory called 'files' and place any auxiliary files there (patches etc.) - in /usr/local/portage/app-admin/jailkit run "ebuild jailkit-VERSION.ebuild digest". Replace VERSION by the current version to be found in this bug report. - run "emerge -av jailkit"
Created attachment 70954 [details] jailkit-1.3-r3.ebuild This ebuild was sent to me. It is the integration of the gentoo-specific patches into the ebuild script. So now there's even less to do when installing this ebuild into your overlay. Many thanks to themgt for integrating the patches into the ebuild and doing some sed wizadry.
*Version bump* 2.0 was released and it seems that renaming 'jailkit-1.3-r3.ebuild' to 'jailkit-2.0.ebuild' does the trick. I haven't run into any problems yet.
I emerged jailkit 2.0 and got this notice: QA Notice: the following files are setXid, dyn linked, and using lazy bindings This combination is generally discouraged. Try re-emerging the package: LDFLAGS='-Wl,-z,now' emerge jailkit LAZY usr/sbin/jk_chrootsh LAZY usr/sbin/jk_procmailwrapper So I emerged: LDFLAGS='-Wl,-z,now' emerge jailkit and it reported: QA Notice: pre-stripped files found: /var/tmp/portage/jailkit-2.0/image/usr/sbin/jk_socketd /var/tmp/portage/jailkit-2.0/image/usr/sbin/jk_chrootlaunch /var/tmp/portage/jailkit-2.0/image/usr/sbin/jk_lsh /var/tmp/portage/jailkit-2.0/image/usr/sbin/jk_chrootsh /var/tmp/portage/jailkit-2.0/image/usr/sbin/jk_procmailwrapper I created a user for ssh and set a chroot environment. I worked fine. In Gentoo portage there is a similar package called app-misc/jail but I believe that its latest software release was made in 2004. The Jailkit project **seems** more active (although I may be wrong). Maybe the sed and grep dependencies in the jailkit ebuild could be removed if the makefile were adequately modified upstream. Anyway, thank you Stephen for putting this ebuild up on bugzilla. Since jailkit hasn't been merged into the portage tree maybe you could propose it to be included in an official overlay (such as the sunrise project): http://overlays.gentoo.org http://www.gentoo-sunrise.org/sunrise/browser/sunrise/app-admin It's just a thought.
(In reply to comment #20) > I emerged jailkit 2.0 and got this notice: > The Jailkit project **seems** more active (although I may be wrong). The mailing list is active and jailkit is being developed slowly but steadily (it has a more or less complete feature set, so new additions are well thought-through and not just thrown in). > Maybe the sed and grep dependencies in the jailkit ebuild could be removed if > the makefile were adequately modified upstream. > http://overlays.gentoo.org Thanks for pointing me out to sunrise - wasn't really aware of it. I'm currently reviewing the ebuild with devlopers on #gentoo-sunrise, so I hope I can get it into sunrise sometime in the future. This of course will cause many changes in the ebuild.
The jailkit ebuild is now in the sunrise overlay. See http://www.gentoo-sunrise.org/sunrise/wiki on how to get the sunrise overlay using layman. Here's the svn path for code freaks: http://gentoo-sunrise.org/svn/reviewed/app-admin/jailkit/ Please don't open new bugs on bugs.gentoo.org, sunrise isn't an official gentoo project, though it is endorsed by many developers. Write to my e-mail address if you find any bugs, or append to this (and only this) bug report. @Vieri: The QA notices are still there. I hope to fix them at some later date.
(In reply to comment #22) > The jailkit ebuild is now in the sunrise overlay. great news Thanks
Stephen: There is a new version of jailkit available (2.1) :-) Could you put an ebuild for the new version into sunrise ?? /Anders
Will do, this weekend. :-)
Finally I've managed to write the ebuild for 2.1 (required some changes compared to 2.0). I've committed it to sunrise and hope it will appear in the tree fairly soon.
How's everyone doing here? jailkit-2.15 has been released this year, anyone here running it?
(In reply to comment #27) > How's everyone doing here? jailkit-2.15 has been released this year, anyone > here running it? You are free to create a new ebuild and submitted to sunrise :)
I don't have an idea yet whether I even need it (NX-related), last comment was a century ago, just checking the pulse here at first :> GPO says there's a 2.14 ebuild in mva overlay.
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
