Tuesday 26 April 2022

Re: pv (a pipeline progress indicator) in main?

On Fri, Apr 22, 2022 at 11:56 PM Thomas Ward <teward@ubuntu.com> wrote:
>
> Generally speaking, could we not ship an apparmor profile with it in
> Ubuntu specifically to prevent default usage of -R and ptracing for the
> application?
>
> If so, then a default apparmor profile to prevent usage of -R (depending
> on how they do it) might be prudent.

The following would do, but since apparmor is an allow-list for mandatory access
that could end up reading weird unless there is a nice trick to
allow-all-but ...

audit deny signal (receive, send) peer=/usr/bin/pv set=("exists"),

> I can see this being useful in Main, provided it passes security review.
>
>
> Thomas
>
> On 4/22/22 17:00, Seth Arnold wrote:
> > On Fri, Apr 22, 2022 at 09:58:14AM -0700, Bryce Harrington wrote:
> >> LP page: https://launchpad.net/ubuntu/+source/pv
> >> Or other considerations that need made before deciding?
> > pv is popular in the OpenZFS communities for use with zfs send | zfs recv
> > -- as is mbuffer, which exists more to provide much larger buffering than
> > the usual libc stdio buffers. mbuffer doesn't have progress bars, but does
> > show throughput:
> >
> > $ dd if=/dev/urandom | mbuffer > /dev/null
> > in @ 32.5 MiB/s, out @ 32.5 MiB/s, 166 MiB total, buffer 0% full^C
> > 341133+0 records in
> > 341133+0 records out
> > 174660096 bytes (175 MB, 167 MiB) copied, 5.13954 s, 34.0 MB/s
> > mbuffer: warning: error during output to <stdout>: canceled
> > summary: 167 MiByte in 5.1sec - average of 32.4 MiB/s
> >
> > One feature of pv that slightly worries me is that you can change the
> > parameters of an already-running instance by running it again, with -R:
> >
> > -R PID, --remote PID
> > If PID is an instance of pv that is already running,
> > -R PID will cause that instance to act as though it
> > had been given this instance's command line instead.
> > For example, if pv -L 123K is running with process ID
> > 9876, then running pv -R 9876 -L 321K will cause it to
> > start using a rate limit of 321KiB instead of 123KiB.
> > Note that some options cannot be changed while
> > running, such as -c, -l, -f, -D, -E, and -S.
> >
> > It's probably fine. (Afterall, it's possible to disable the yama sysctl
> > kernel.yama.ptrace_scope and attach a debugger to the process to modify
> > whatever you want.) But it's also possible it's not fine.
> >
> > Thanks
> >
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel