Subject: Re: pkg_delete "Executing" output
To: Jeremy C. Reed <email@example.com>
From: Alistair Crooks <firstname.lastname@example.org>
Date: 02/10/2005 10:11:28
On Wed, Feb 09, 2005 at 10:44:29AM -0800, Jeremy C. Reed wrote:
> On Wed, 9 Feb 2005, Alistair Crooks wrote:
> > > pkg_delete was changed to output "Executing" lines from rmdir, etc.
> > >
> > > This can make for a lot of output, such as updating perl which has at
> > > least a couple screen fulls scroll by.
> > >
> > > Can we have the "Executing" lines be optional based on the Verbose switch?
> > They used to be based on the verbose switch. I modified it so that
> > they weren't.
> > The reason for this is one of security. For almost all users, these
> > commands are run as the root user; the commands are taken from a file
> > in the filesystem hierarchy (which is not itself checksummed). From a
> > security POV, I want to know what commands are being run, even if you
> > don't want to, because files can be modified, made to point to
> > additional scripts, etc.
> I am not sure how this could be useful for security. Having numerous
> "rmdir" lines scroll by makes it so nobody would want to read the output
> in the first place and it also hides any more interesting messages.
I don't understand your logic. Just because you are presented with a
lot of information, does that make the information itself useless?
> Anyways, we trust that the package didn't install anything malicious in
> the first place and we already trust the INSTALL and DEINSTALL scripts.
That is a good argument for showing what is happening in the INSTALL
and DEINSTALL scripts, yes.
> > FYI, this was a fix that was requested a number of years ago by the
> > NetBSD security officer, and I have only just got around to fixing it.
> The NetBSD security officer wanted hundreds of "rmdir" messages scrolling
> by? Maybe we can make it so it doesn't report it when it is rmdir?
Again, I don't understand your logic - why is rmdir(1) a command which
is trusted more than rm(1)? Why is rmdir safer than ln(1)?