Subject: Bug#3189: nvi over-cautious about .exrc?

From: [email-masked] (Bruce Perens)
Date: Mon, 3 Jun 96 17:30 PDT

> Not much trouble if it is just one machine.  Some time ago I had to
> install 10 machines as X workstations which don't need to handle mail
> at all, and need no user accounts (NIS).  I had to answer all these
> questions about user names and passwords only to delete these accounts
> later.  I don't want to do unnecessary work, lazy me :-).  FYI, when
> I installed SCO OpenServer 5, it asked me for root password (Debian
> does it too, good), but didn't require that I create a new user account
> immediately.

What we really need to support this case is a means of loading some
amount of pre-configuration on to the root floppy when doing large-site
installs. You should be able to pre-configure the root password (stored
in encrypted form) and most of the other installation questions except
for "what is my host name and IP number".

It would make sense to provide a menu reachable from the main menu that
configures the installation defaults and lets you make policy decisions
like "don't create any users". This information would be written back
onto your root floppy. This would be much more appropriate for large-site
installs. The problem with the present installation menu is that it is
written for one-system installs, and it's not really appropriate for anything
else.

> Hmm.  I can't chgrp my own files to any group I am not a member of.

I meant that the _super-user_ could run a script to convert users and their
files to belong to a centralized group. You have to be root to install the
quota package anyway, this could be a post-inst option.

	Thanks

	Bruce
--
Pixar's Toy Story: Over 1/3 Billion dollars world box office so far.

Bruce Perens AB6YM          [email-masked]            http://www.hams.com/

---

From: Bill Mitchell <[email-masked]>
Date: Tue, 4 Jun 1996 08:15:56 -0700 (PDT)

Ian Jackson
> > >It is not the business of programs to check the permissions of the
> > >dotfiles in users' home directories.

Bill Mitchell:
> > I agree.  I chased my tail for quite a while some time back because of
> > what I recall as procmail's concern over the permissions on my .forward
> > file.  It didn't complain, it just didn't work as I expected from reading
> > the docs.

Oliver Oberdorf:
> But for a large system with many users (of varying levels of clue) it
> is very beneficial for the SysAdmin that a user can't accidentally create
> a writeable .forward file.

But having one fairly obscure app (procmail) break in a confusing manner
if it encounters a group-writable .forward file doesn't stop users from
creating such a file.  In particular, it does not stop the large majority
of users who don't use procmail.

For a sysadmin to depend on the procmail program to provide security
in this area is futile.  He'd be better off to run a system security
auditing program (cops? others?) , or use a tool like cfengine(1) to
script up a security audit customized to his particular system situation.

For the procmail program to do a less than stellar job of dealing
piecemeal with what it perceives as an isolated possible security
problem is likely to be ineffective and/or counterproductive.

(note: not to pick on procmail specifically here -- it just happens
to be a live example which came to mind)