[Toybox] alias tar="tar --restrict"

[enh]

On Thu, Apr 11, 2019 at 3:29 PM Rob Landley <rob at landley.net> wrote:
>
> On 4/11/19 11:34 AM, enh wrote:
> > On Fri, Apr 5, 2019 at 8:44 PM Rob Landley <rob at landley.net> wrote:
> >>
> >> I just added --restrict to require all the tarball's contents to extract under a
> >> single directory, and the obvious way to use it is the same as ls --color, via
> >> alias.
> >>
> >>   $ tar cz linux-4.20 l*.txt > ll.tgz
> >>   $ tar xvf ../ll.tgz --restrict
> >>   ...
> >>   linux-4.20/net/x25/x25_link.c
> >>   linux-4.20/net/x25/x25_proc.c
> >>   linux-4.20/net/x25/sysctl_net_x25.c
> >>   l11.txt
> >>   tar: 'l11.txt' not under '/home/landley/toybox/toy3/tartest/sub/linux-4.20'
> >>   l1.txt
> >>   tar: 'l1.txt' not under '/home/landley/toybox/toy3/tartest/sub/linux-4.20'
> >>   l2.txt
> >>   tar: 'l2.txt' not under '/home/landley/toybox/toy3/tartest/sub/linux-4.20'
> >>   $
> >>
> >> Except... tar xvzf not needing dash is because the first argument is treated
> >> specially, and extra arguments from alias come first. Do you suppose that should
> >> be the first _non-longopt_ argument, maybe?
>
> I guess I should assume that this is the case then?
>
> >> P.P.S. The gnu/dammit --restrict is utterly useless, it disables the ! command
> >> to spawn a subshell when prompting to change tapes. No really. They added this
> >> in 2005. I reused it because as long as they already added a NOP it means you
> >> can feed --restrict to both and it'll just work.
> >
> > i think this came up before, but i think this is pretty much the worst
> > possible choice with option naming... if i'm thinking of toybox and
> > i've asked tar to do something, the _last_ thing i want GNU tar to do
> > is silently ignore what i asked for. i'd much rather GNU tar forced me
> > to think about whether i actually don't care, or need to do something
> > special, or need to make sure i'm actually running toybox tar.
>
> Agreed in general, but in this case for 99% of tarballs --restrict is a NOP. And
> even when it isn't, we still reject extracting into anyting above $PWD. (If you
> want to extract into the root directory, -C / exists. Currently, we will not
> follow symlinks out of our working directory under any circumstances. Slows
> things down slightly taking an abspath of each entry, but that's mostly dentry
> cache after the first time and my tests are still disk limited.)
>
> > (in general the other direction is dangerous too, but in this specific
> > case i'm pretty sure no-one wants to change tapes on Android or during
> > an AOSP build --- though you'd be surprised by some of the requests we
> > do get from folks who don't value hermetic builds quite as much as we
> > do!)
>
> If they ask here, I'll take it into consideration. :)

aye, but not for long... the number #1 request is perl :-)

the only reasonable request i've heard so far was seq, which we
already have on the device so we've allowed that in the build too.
(the stuff available to the build is an as-needed subset of the stuff
on the device. (and, no, i don't know what they're using seq for. i'm
mildly curious myself.))

> (And if somebody asks for toybox to do something that busybox or posix already
> has, that's like 80% of the way to me biting the bullet and adding it.)
>
> > ((it's a shame GNU wasted a good name on a no-op though.))
>
> *shrug* Pick a name and I'll rename it, not tied to that.

i didn't have any particularly good suggestions --restrict-paths?
--restrict-directory?

> (I note that gnu/dammit -a is "autodetect compression type" and busybox -a is
> "lzma", which was added after my time on the project. I.E. I didn't start this...)

well, this is why i don't like adding new short options --- collisions
are almost certain. (although, yes, even for long options some names
are more tempting than others...)

> Rob