Toybox
Contents
ToyBox solution analysis in a Tizen context
Since GPLV3 license requires to publish the installation process, it pose a problem to many managed platform manufacturers (Phone, IVI, TV, ...) In that context, it seems necessary to find an alternative solution for in replacement of the current Coreutils package, since it presents a GPLV3 License.
The purpose of this page is to analyze one of these alternative : Toybox, and describes to what extent it could be integrated in a Tizen environment.
What is Toybox ?
Toybox is an active BSD-licensed project that provides the most common Linux command line utilities into a single executable.
It offers a simple, small, fast and reasonably standards-compliant implementation of such core utilities.
(see : http://landley.net/toybox/about.html)
NOTE : This analysis is based on the latest stable release : 0.4.9
Toybox's current status
The project's website describes well the current status (see : toybox status ).
The latest stable release (0.4.9) provides the following commands (including the pending toybox commands) :
/usr/bin : blkid, cat, chattr, chgrp, chmod, chown, cksum, cp, cpio, cut, date, dmesg, dos2unix, echo, egrep, false, fgrep, fstype, ftpget, ftpput, grep, halt, head, help, hostname, id, ifconfig, insmod, kill, last, ln, login, logname, ls, lsattr, lsmod, mkdir, mkfifo, mknod, mktemp, modinfo, mountpoint, mv, nc, netcat, netstat, nl, openvt, paste, pmap, poweroff, ps, pwd, readahead, readlink, reboot, renice, rm, rmdir, rmmod, route, sed, sh, sleep, stat, su, swapoff, swapon, sync, tail, taskset, tee, telnet, tftpd, timeout, touch, toybox, toysh, true, truncate, umount, uname, uniq, unix2dos, usleep, vmstat, who, whoami
/usr/sbin : addgroup, adduser, delgroup, dhcp, dhcpd, fdisk, freeramdisk, getty, groupadd, groupdel, init, killall5, klogd, losetup, mke2fs, mkswap, modprobe, oneit, partprobe, rfkill, sulogin, switch_root, syslogd, useradd, vconfig
As we can see, Toybox overwrites for many common commands from several packages : Coreutils, util-linux, sed, etc ...
In order to have a better visualization of what Toybox provides or not in a Tizen environmnent, I made the following document:
- This document presents all commands provided by both coreutils and toybox packages.
- In addition, I have also represented commands already provided util-linux package, and other alternatives packages that also implements missing toybox commands regarding to the coreutils package.
Regarding to pending works to do, it seems that next releases of toybox should offer an acceptable alternative to coreutils.
Toybox's architecture and implementation
The architecture is quite simple, and offers an easy understanding.
Source code is dispatched in different repositories, depending to the current status (pending) and the implementation norm (POSIX, LSB, others...).
./toys : ./example ./lsb ./other ./pending ./posix
In my opinion, source code is well developed and reasonably commented.
As far as I could see, all basic command options have been implemented.
Adding an option to a specific command would not take more than a few minutes.
See as an example the chmod command implementation :
/* chmod.c - Change file mode bits * * Copyright 2012 Rob Landley <rob@landley.net> * * See http://opengroup.org/onlinepubs/9699919799/utilities/chmod.html USE_CHMOD(NEWTOY(chmod, "<2?vRf[-vf]", TOYFLAG_BIN)) config CHMOD bool "chmod" default y help usage: chmod [-R] MODE FILE... Change mode of listed file[s] (recursively with -R). MODE can be (comma-separated) stanzas: [ugoa][+-=][rwxstXugo] Stanzas are applied in order: For each category (u = user, g = group, o = other, a = all three, if none specified default is a), set (+), clear (-), or copy (=), r = read, w = write, x = execute. s = u+s = suid, g+s = sgid, o+s = sticky. (+t is an alias for o+s). suid/sgid: execute as the user/group who owns the file. sticky: can't delete files you don't own out of this directory X = x for directories or if any category already has x set. Or MODE can be an octal value up to 7777 ug uuugggooo top + bit 1 = o+x, bit 1<<8 = u+w, 1<<11 = g+1 sstrwxrwxrwx bottom Examples: chmod u+w file - allow owner of "file" to write to it. chmod 744 file - user can read/write/execute, everyone else read only */ #define FOR_chmod #include "toys.h" GLOBALS( char *mode; ) int do_chmod(struct dirtree *try) { mode_t mode; if (!dirtree_notdotdot(try)) return 0; mode = string_to_mode(TT.mode, try->st.st_mode); if (toys.optflags & FLAG_v) { char *s = dirtree_path(try, 0); printf("chmod '%s' to %04o\n", s, mode); free(s); } wfchmodat(dirtree_parentfd(try), try->name, mode); return (toys.optflags & FLAG_R) ? DIRTREE_RECURSE : 0; } void chmod_main(void) { TT.mode = *toys.optargs; char **file; for (file = toys.optargs+1; *file; file++) dirtree_read(*file, do_chmod); }
Integration in Tizen environment
Building toybox is quite fast forward since it works the same way as a kernel does.
- It uses a defconfig file which permits to activate / deactivate a specific command to be built.
- All generated commands are symlinks that point to a single binary : /usr/bin/toybox .
NOTE : Toybox is not supposed to replace coreutils in a Tizen build ; it could lead to some major issues in an OBS due to some depedency conflicts.
Toybox is only supposed to replace coreutils commands at a runtime level, in final generated images.
ToyBox and security in Tizen
For some read/write based commands, we will have to add/modify options, in order to provides the same security based functionalities.
for example:
ls -Z option ps -Z cp --preserv-all . . etc . .
Those commands have been represented in the detailed status with '*' symbol.
Runtime status in Tizen
I have packaged a toybox version that only overwrites coreutils commands and install it on a tizen common (wayland x86_64) image.
As far as I could test the resulting image, no runtime issues have been noticed. But a deeper investigation at runtime level should be useful to get a more precise status.
