8492dee663
Closes #154 When starting any operation to do with subuid delegation, check nsswitch for a module to use. If none is specified, then use the traditional /etc/subuid and /etc/subgid files. Currently only one module is supported, and there is no fallback to the files on errors. Several possibilities could be considered: 1. in case of connection error, fall back to files 2. in case of unknown user, also fall back to files etc... When non-files nss module is used, functions to edit the range are not supported. It may make sense to support it, but it also may make sense to require another tool to be used. libsubordinateio also uses the nss_ helpers. This is how for instance lxc could easily be converted to supporting nsswitch. Add a set of test cases, including a dummy libsubid_zzz module. This hardcodes values such that: 'ubuntu' gets 200000 - 300000 'user1' gets 100000 - 165536 'error' emulates an nss module error 'unknown' emulates a user unknown to the nss module 'conn' emulates a connection error ot the nss module Changes to libsubid: Change the list_owner_ranges api: return a count instead of making the array null terminated. This is a breaking change, so bump the libsubid abi major number. Rename free_subuid_range and free_subgid_range to ungrant_subuid_range, because otherwise it's confusing with free_subid_ranges which frees memory. Run libsubid tests in jenkins Switch argument order in find_subid_owners Move the db locking into subordinateio.c Signed-off-by: Serge Hallyn <serge@hallyn.com> |
||
|---|---|---|
| .. | ||
| chage | ||
| chroot | ||
| chsh | ||
| cktools | ||
| common | ||
| convtools | ||
| cptools | ||
| crypt | ||
| debian | ||
| expiry | ||
| failures | ||
| grouptools | ||
| libsubid | ||
| log | ||
| login | ||
| newgidmap | ||
| newuidmap | ||
| newusers | ||
| passwd | ||
| split_groups | ||
| su | ||
| subids | ||
| usertools | ||
| README | ||
| bug332198-test.exp | ||
| bug334803-test.exp | ||
| cleanup.sh | ||
| coverage.sh | ||
| run_all | ||
| run_all.coverage | ||
| run_some | ||
README
This testsuite is NOT SECURE: it will temporarily change your passwords file with known passwords. You should run it on a chroot, or on a secured dedicated system. To test a Debian system: $ mkdir sid-chroot $ sudo debootstrap sid sid-chroot/ http://ftp.fr.debian.org/debian/ edit or copy a sources.list $ sudo cp /etc/apt/sources.list sid-chroot/etc/apt/ edit or copy a resolv.conf $ sudo cp /etc/resolv.conf sid-chroot/etc/ $ su - root -c "chroot sid-chroot/ /bin/bash" # mount -t proc proc /proc # mount -t devpts devpts /dev/pts # aptitude update # aptitude install expect # cd /dev ; mknod --mode=666 /dev/ptmx c 5 2