You're right. I am a part of a community distro which uses busybox by
default, and we need something to be able to change privileges to an
arbitrary user, but it is not portable to expect a tool to print all of
a username longer than 8 characters. Using the UID is more reliable.
There is no standard for su, but my hope with this patch is for there
to be one more tool with which our problem can be solved; it's nice to
have more options.
As much as I understand and sympathize with your plight - I'm the
first one to complain about the low quality of "traditional" low-level
userspace on Linux - I don't think your approach is the right solution.
"su" has - more or less - a known interface, and is - more or less -
usable on every distribution; a script using su will generally be
portable from one distro to another.
Adding an option to busybox su that is not supported by util-linux su
destroys that guarantee, and fragments the user space even more than it
already is. "su -n" will only be usable with busybox, so to an external
viewer, it's more confusing than anything else why the tool is called
su.
Only use existing tool names when you provide an interface that's
exactly compatible with the existing tool; else you will weaken the
reach and usefulness of the tool. If you need new functionality,
implement the functionality as a separate tool, that can take
inspiration from the existing tool for its name and interface, but
you should call it ben-su rather than su. Introducing a divergence
in busybox su is harmful in the long run.
(This is why GNU coreutils is so difficult to replace: it has
embraced and extended, and now the world is full of scripts relying
on cp --useless-options that every potential replacement has to
implement.)
For non-interactive applications of su with numeric uids, may I suggest
https://skarnet.org/software/s6/s6-applyuidgid.html ?
--
Laurent
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
