From debian-devel@pixar.com Sun Mar 20 22:54:49 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA23381; Sun, 20 Mar 94 22:54:47 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0piazQ-0005oqa; Sun, 20 Mar 94 19:49 PST
Date: Sun, 20 Mar 94 19:49 PST
Message-Id: <Pine.3.89.9403181730.A29958-0100000@sydte3>
Errors-To: bruce@pixar.com
Reply-To: charlieb@tplrd.tpl.oz.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Charlie Brady <charlieb@tplrd.tpl.oz.au>
To: debian-devel@pixar.com
Subject: Re: debian-bugs@pixar.com -> debian-devel@pixar.com
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


On Thu, 17 Mar 1994 bruce@beagle.pixar.com wrote:

> At Ian Murdock's request, I have the debian-bugs@pixar.com alias set
> to forward to the debian-devel mailing list. This will save Ian from
> forwarding the messages by hand.
> 
> In the long term, we might consider having a volunteer (or volunteers)
> who will take bug reports, forward them to the appropriate package
> maintainer, _track when they are repaired_, and maintain a publicly
> accessable bug list. Is anyone interested in this?

Has anyone looked at "gnats" to see if it is suitable for automating
bug tracking. Here is some blurb from Gnu.announce:

   * Gnats 3.01

     Gnats (GNats: A Tracking System) is a bug-tracking system.  It is based
     upon the paradigm of a central site or organization which receives
     problem reports and negotiates their resolution by electronic mail.
     Although it's been used primarily as a software bug-tracking system so
     far, it is sufficiently generalized so that it could be used for
     handling system administration issues, project management or any number
     of other applications.


Charlie Brady * (W) charlieb@tplrd.tpl.oz.au * (H) charlieb@budge.apana.org.au
"Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
  but no simpler"   Einstein, A  | Fax: (02) 413 6060 Pacing Systems    \/  


From debian-devel@pixar.com Sun Mar 20 22:56:43 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA23433; Sun, 20 Mar 94 22:56:40 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pib1G-0005o7a; Sun, 20 Mar 94 19:51 PST
Date: Sun, 20 Mar 94 19:51 PST
Message-Id: <Pine.3.89.9403211156.I7463-0100000@sydte3>
Errors-To: bruce@pixar.com
Reply-To: charlieb@tplrd.tpl.oz.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Charlie Brady <charlieb@tplrd.tpl.oz.au>
To: debian-devel@pixar.com
Subject: Re: Guidelines
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


On Thu, 17 Mar 1994, Bill Mitchell wrote:
> 
>         It's conceivable that debian 1.1 might make a rule that all programs
>         which have default editors are to dofault to emacs for consistancy.
  .....
> 
> Comments on the above, anyone?

This is a joke, isn't it? I don't see any smilies.

Charlie Brady * (W) charlieb@tplrd.tpl.oz.au * (H) charlieb@budge.apana.org.au
"Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
  but no simpler"   Einstein, A  | Fax: (02) 413 6060 Pacing Systems    \/  


From debian-devel@pixar.com Sun Mar 20 22:59:56 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA23470; Sun, 20 Mar 94 22:59:53 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pib4N-0005pNa; Sun, 20 Mar 94 19:54 PST
Date: Sun, 20 Mar 94 19:54 PST
Message-Id: <Pine.3.89.9403211119.J7463-0100000@sydte3>
Errors-To: bruce@pixar.com
Reply-To: charlieb@tplrd.tpl.oz.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Charlie Brady <charlieb@tplrd.tpl.oz.au>
To: debian-devel@pixar.com
Subject: Re: Guidelines
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


On Thu, 17 Mar 1994, Bill Mitchell wrote:

> I suggested that the .tgz file for all packages include a
> CHANGES.debian.version file (version starts at 0 and increments with
> each new debian release of that package-release).  This file would contain 
> the following information:
> 
>     A.  The origin of the source code distribution kit
>     B.  The identity of the person packaging the distribution for debian
>     C.  The version of the compiler used to produce the package
>     D.  The version(s) of all libraries linked in
>     E.  A debain-specific release designation the CHANGES file of this
>         distribution (e.g., less-177.debian.0).  This would only
>         appear in the CHANGES.debian.version file, it need not effect
>         other filenames in the distribution.
>     F.  The CHANGES file should contain  step-by-step narrative of the changes
>         made to package distribution files in order to produce this debian
>         distribution.  This should start with untar-ing the package 
>         distribution, and should include any steps taken to configure the 
>         package, and non-default responses to configure scripts, and special 
>         edits made to package files (such as adding the debian-standard
>         definitions to Makefile, etc.)
etc....

I think that Bill's reasoning is sound (apart from the "vi" to "emacs" 
change). The only problem that I have with it is that it might be
ambiguous, whereas a context diff is definitive.. Perhaps both
need to exist, the context diff so that so that anyone can easily rebuild
exactly the distributed binary, and the CHANGES file as a resource to a
subsequent developer.

In any case, wherever the CHANGES file says, "edit file so-and-so", a 
context diff is appropriate.

Is Bill suggesting that the CHANGES file is distributed with the binary 
distribution? If so, why and where will it be installed?

Charlie Brady * (W) charlieb@tplrd.tpl.oz.au * (H) charlieb@budge.apana.org.au
"Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
  but no simpler"   Einstein, A  | Fax: (02) 413 6060 Pacing Systems    \/  


From debian-devel@pixar.com Sun Mar 20 23:31:15 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA23692; Sun, 20 Mar 94 23:31:12 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pibYg-0005pFa; Sun, 20 Mar 94 20:25 PST
Date: Sun, 20 Mar 94 20:25 PST
Message-Id: <Pine.3.89.9403202301.A11797-0100000@vani>
Errors-To: bruce@pixar.com
Reply-To: mbailey@cps201.cps.cmich.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Matt Bailey <mbailey@cps201.cps.cmich.edu>
To: debian-devel@pixar.com
Subject: Re: Guidelines
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO



I think that we should do a little vote on this....

I have many users here that all we teach to them is Emacs...
I am not suggesting that it be default but isn't vi a little hard to use 
for a beginner?? I like maybe pico or something for mail and then since 
you would probably have it for mail to use it as default for anything 
else that calls editors like newsreaders.....

It is small and funtional so I like the idea of it better than emacs but 
I really don't like the idea of vi for the joe smo that might be using 
it.....

Or even a patch set that would make everything use one of the other editors 
instead of vi....


On Sun, 20 Mar 1994, Charlie Brady wrote:

> 
> On Thu, 17 Mar 1994, Bill Mitchell wrote:
> > 
> >         It's conceivable that debian 1.1 might make a rule that all programs
> >         which have default editors are to dofault to emacs for consistancy.
>   .....
> > 
> > Comments on the above, anyone?
> 
> This is a joke, isn't it? I don't see any smilies.
> 
> Charlie Brady * (W) charlieb@tplrd.tpl.oz.au * (H) charlieb@budge.apana.org.au
> "Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
>   but no simpler"   Einstein, A  | Fax: (02) 413 6060 Pacing Systems    \/  
> 
> 

--
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||                                ||  root@stimpy.cps.cmich.edu      ||
|| Matthew S. Bailey              ||  mbailey@cps201.cps.cmich.edu   ||
|| 109 Merrill Hall               ||  32bdzwc@cmuvm.csv.cmich.edu    ||
|| Central Michigan University    |||||||||||||||||||||||||||||||||||||
|| Mt. Pleasant  MI  48858        ||  Get rid of MS-DOG and switch   ||
|| (517) 774-4141                 ||  To a real Operating System     ||
||                                ||         L I N U X!!             ||
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||








From debian-devel@pixar.com Mon Mar 21 00:42:41 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA23961; Mon, 21 Mar 94 00:42:38 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0picfo-0005oja; Sun, 20 Mar 94 21:37 PST
Date: Sun, 20 Mar 94 21:37 PST
Message-Id: <Pine.3.89.9403202153.A18728-0100000@bb29c>
Errors-To: bruce@pixar.com
Reply-To: mitchell@mdd.comm.mot.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Bill Mitchell <mitchell@mdd.comm.mot.com>
To: debian-devel@pixar.com
Subject: Re: Guidelines
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


On Sun, 20 Mar 1994, Charlie Brady wrote:

> 
> On Thu, 17 Mar 1994, Bill Mitchell wrote:
>[...] 
> I think that Bill's reasoning is sound (apart from the "vi" to "emacs" 
> change). The only problem that I have with it is that it might be
> ambiguous, whereas a context diff is definitive.. Perhaps both

Definitive, but not comprehensive.  In the case of less-177, all the
changes show up in files which are created by running the configure 
script, and by doing further linux-specific edits to files created
by the script.  The context diff reports the existance of these new 
files, but not their contents, and not what linux-specific configuration 
script responses and subsequent linux-specific file edits produced them.

> need to exist, the context diff so that so that anyone can easily rebuild
> exactly the distributed binary, and the CHANGES file as a resource to a
> subsequent developer.

The context diff doesn't contain sufficient information to reproduce the
distributed binary starting with a standard source distribution, at least 
not in the case of less-177.  And less-177 is a pretty simple case.  The 
CHANGES file would provide this missing information.  (CHANGES.debian.version
might have been a bad choice for the file name.  Perhaps README instead of 
CHANGES would be better).

> 
> In any case, wherever the CHANGES file says, "edit file so-and-so", a 
> context diff is appropriate.
> 

But if file so-and-so was created by a configuration script and did not 
exist in the original source distribution, the context diff only reports 
the existance of this new file -- not its contents and not what 
configuration script responses and edits went into producing it.

> Is Bill suggesting that the CHANGES file is distributed with the binary 
> distribution? If so, why and where will it be installed?

No.  It's only of interest if the binaries are being rebuilt from sources.
It's intended as an aid when a debian package distribution which had been 
maintained by one maintainer is taken over by another maintainer, or for 
anyone else interested in building his own binaries starting with debian 
package sources.

Ian't guidelines say that debian package sources should (strive to) build 
and install completely with a simple "make install", so they'd contain 
the complete files, and the context diffs not reporting their contents 
wouldn't be a problem.  I'm thinking that information on how these 
files were produced, and perhaps some remarks on the reasoning behind the 
configuration choices which led to them, might be useful.

mitchell@mdd.comm.mot.com (Bill Mitchell)



From debian-devel@pixar.com Mon Mar 21 09:37:12 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA25516; Mon, 21 Mar 94 09:37:09 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pil15-0005qra; Mon, 21 Mar 94 06:31 PST
Date: Mon, 21 Mar 94 06:31 PST
Message-Id: <9403211430.AA23612@sugar-bombs.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: debian-bugs@pixar.com -> debian-devel@pixar.com
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Sun, 20 Mar 94 19:49 PST
   From: Charlie Brady <charlieb@tplrd.tpl.oz.au>

   Has anyone looked at "gnats" to see if it is suitable for automating
   bug tracking. Here is some blurb from Gnu.announce:

[...]

I was going to ask the same question.  Has anyone used it?  It sounds
like it just might fit our needs.

BTW, we're still looking for someone.  Matt Bailey offered to do it,
but we really need someone who can do it beyond May.  I would rather
not have to go through any more transfers of responsibility than
necessary.

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Mon Mar 21 06:23:05 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA24335; Mon, 21 Mar 94 06:23:01 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pihzD-0005h2a; Mon, 21 Mar 94 03:17 PST
Date: Mon, 21 Mar 94 03:17 PST
Message-Id: <m0piQcA-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: user private groups and a src group
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

I shall delimit responses to different people with rows of `=' signs.

I've sorted my replies so that approximately what are IMO the most
sound, nonrepetitious and interesting arguments are near the top.  I
have to say that I'm rather disappointed with the poor standard of
many of the arguments being used to oppose my proposal.  I had hoped
for better from the developers' list.

I'm getting really quite tired of all the non-arguments against my
proposal, not the least of which is "other people don't seem to like
it."

====================

Remy Card writes:
>          [ Source code control is a good thing, therefore ]
>         1. write access to a common set of files by a development team
>            is not needed (and not even desirable) to achieve a project
>            with efficiency,

Not every shared project has many people all updating the same source
files all the time, and therefore not every project needs to use RCS
or an equivalent.

And, as Matthew Birkholz has pointed out, RCS doesn't work unless the
users using it have shared access to the repository.

On very few of the shared projects I have worked on has it been
necessary to use source code control.  Perhaps the projects I work on
have been less formally managed than others, but they prove the
existence (frequently!) of projects where this is the case.

>[rest of argument deleted as it doesn't follow if I refute the premise]
>
>         Of course, I'll be glad to hear about conter examples (important
> ptojects which cannot be achieved with the help of a version control
> system and which require a change in the uid and gid attribution).

I have answered most of this above.  However I'll also say that often
a version control system can be a help rather than a hindrance; even
if it were able to solve the same problem as the private groups
proposal (which it isn't) one shouldn't assume that it is the right
solution for everybody.

====================

Glen Reesor writes:
> These two quotes bring to mind an issue I haven't seen mentioned yet--
> that of sharing filesystems via NFS with machines that do *not* use
> this uid=gid method.  Won't it be a major pain to align the two
> machines' group and passwd files??

No more than it is anyway.  In this case the uid=gid can be abandoned
quite easily.  You simply change the default umask to 022 and copy the
shared passwd and group files verbatim onto your system.

The setgid bit on each directory can be left alone, as it then ceases
to have any meaningful effect on the permissions of files created
there.

====================

Paul Vojta writes:
>         Scripts just don't cut it.  For starters, they either produce
>         subshells which must be tediously nested, or have to be sourced or
>         whatever and are thus a right royal pain.
> 
> One can use aliases to source commands.

Yes, I'm aware of this; my description of it as a "right royal pain"
stands.  It requires everyone who wishes to use these groups to make
bizarre shell-specific alterations to their dotfiles.  They must then
remember each time they start and stop work in the shared filespace to
type the command (in each shell).  They end up having several emacsen,
one for each umask/gid combination.

I have actually used systems like this, and it is a really serious
barrier to getting things done.

>         The one major system I came across recently where it wasn't done
>         wished they had done it, but they couldn't now because they'd already
>         assigned the uid/gid numbers and they were too hard to change.
> 
> This I don't understand.  What is the value of having gid=uid?  

You've misunderstood me.  The reason they couldn't do it was because
it would require changing users' passwd and group entries on too many
different machines, etc., not because they'd already assigned the
gids.

However, having gid==uid is a useful feature to add to my proposal
because it enhances consistency and therefore makes administration
easier.  It would also make it possible to (for example) go for
uid/gid unification in the kernel (cf the Hurd).

> I disagree.  Outside of the kernel, how often is it really true that you
> have multiple users working on common projects?  At the UCB math department,
> for example, the vast majority of users do not collaborate at all.

I have worked on numerous shared projects.  I can't speak for all
users, of course, but given that the cost of my proposal is so low it
is silly to make life so awkward for those who wish to do this
perfectly reasonable thing.

> Regarding the kernel example, it is a dangerous practice, IMHO, to allow
> people to modify the kernel but not give them root access.  They would then
> have both the ability and the incentive to introduce security holes into
> the kernel.

Do you always do your kernel compilations as `root' ?  I don't like
to.  It makes it more likely that I will (for example) accidentally
wipe out half my system with a misplaced `rm'.

Also, I'm not necessarily suggesting that the group of people with
write access to the kernel source should be greater than those who can
su to root with no password.

> Again, what is the benefit of having gid=uid?

See above.  I believe that we should have gid=uid in Debian, for
consistency.  It's not required for my proposal to work.

>  This seems to be more of
> a religious issue than anything else.

Here "religious issue" seems to be being used by many as an excuse to
avoid finding rational arguments to support their position.  There are
plenty of good arguments on our side, after all.

I'm not speaking from a "religious" perspective: the reason I believe
in this so strongly is because I have had extensive experience of this
problem and found that it _is_ serious and that the solution I am
proposing for Debian solves it easily, cleanly and effectively.

>  But if you abandon that requirement,
> you can migrate quite readily from the old system to this one on an as
> needed basis:  to switch joeuser to having his own group, just:
> 
>         1.  create a group named "joeuser" and add joeuser to it
>         2.  chgrp -R joeuser ~joeuser
>         3.  chmod g+s ~joeuser

No, that doesn't work.  joeuser has to set his umask to 002 as well.
Then when he goes to edit system files, etc. for example (using su,
perhaps), the permissions will be wrong, unless you set g+s on each
directory.

If you do that you might as well make use of it properly.

Also, you have to do this for every person who becomes a member of a
shared project.  Why go to all this trouble ?

> So why don't we keep the default debian behavior as it is currently, and
> allow an option in adduser (and /etc/defaults/adduser or wherever it is)
> to use Ian's system?

Why does the default have to be broken ?

====================

Carl Powers writes:
> Matt Hannigan writes:
> > However Ian Jackson
> > and I are both convinced that this scheme will bring no real changes
> > to the vast majority of debian users anyway, and a significant
> > advantage to those few that want to take advantage of group
> > permissions.
> 
> The difference between 'vast majority' and 'all' is 'some'.  Is that 'some'
> of less importance than 'those few' who would benefit from such a scheme?

You have not shown how my proposal harms the `some'.  I don't believe
my scheme will significantly inconvenience *anyone* (well, anyone
reasonable).

> You and Ian have proposed a perhaps simple and elegant solution to a problem
> affecting 'those few'.  Wouldn't it be better to provide a solution only
> applicable to 'those few', which could be selected or retrofitted at install
> time?  I am one of the 'some'.  I desire to keep my uid and gid separate and 
> different on my linux box at work, to match those on the non-debian system I
> am hosted on.  This avoids having to change ownership/permissions when 
> transfering/downloading files between systems. 

What's the problem here ?  In your case you have to rip out Debian's
/etc/group and /etc/passwd files anyway, and can't use Debian's
adduser.  The only additional work for you is to change the default
umask from 002 to 022.

Alternatively, as Matthew Hannigan suggests, you can just change the
umask and leave the /etc/group alone.  After all, if your umask is 022
you're not using the groups anyway and the contents of /etc/group will
make little difference.

> Incidentally, technical feasability and need do not constitute the
> sole arguments for implementing any such change.  You and Ian should be
> prepared to handle the 'philosophical' or 'religious' objections to such
> a change from the norm without insulting the intelligence of those who
> object.

I'm perfectly happy to answer genuine philosophical objections (Daniel
Quinlan has made a stab at one, for example).  However saying that an
objection is "religious" is no excuse for failing to back it up.

Personally I feel that the proposal is an elegant solution to a
longstanding problem, and also one which fits in well with potential
future trends in the GNU software at least.

====================

Wayne Schlitt writes:
> I think we really need to question the premise that this change needs
> to be done at all.  It is my understanding that the problem that this
> would solve is when you have lots of people working in the same
> directory tree.  I guess I don't see that happening much for the
> typical debian user.  I also don't see that it is going to be that
> hard for people to customize their environment in those cases that
> there are lots of people working in the same tree.

You obviously haven't tried this.  I have.

In every case where I have had people sharing an area of filespace on
a Unix system exactly one of the following two things was true:

 1. We had umask 002 and user private groups.
 2. There were continual problems with setup files not running
    correctly, files having the wrong permissions, security holes,
    etc. etc. etc.  It was a real pain.

> Maybe I am way off base on all of this.  What exactly was the goal of
> this?  What were the choices?  I am embarassed to admit it, but I
> deleted the original messages that started this thread...

I shall repost my summary article from a few days ago, with some
clarifications.

>  As usual
> with this type of thing, we have spent a lot of time picking minor
> holes in each others articles without looking at the whole.  

I have hardly seen any holes at all picked by the "opposing" camp.
There have been very few messages even worth responding to.  Finally
it seemed that in order to prevent argumentam ad nauseam from carrying
the day I would have to respond to them all, hence this message.

====================

Daniel Quinlan writes:

> I'd rather it was just the default Linux behavior, but it isn't going
> to happen.  I wish that we didn't have to even think about mucking
> around with /etc/group.

The phrase `mucking around' is unjustifiably pejorative.

It appears to me as if you would like to see a more radical scheme,
more along the lines of the unification of user and group ids.

If this were to be done one would still need to specify somewhere
which groups had which actual users as members, and /etc/group is this
somewhere.  In the straightforward implementation, therefore, each
user would end up with an entry in /etc/group anyway !

I don't think that giving every user their own group and corresponding
entry in /etc/group is ugly; it seems to me fairly neat and
orthogonal.

> Anyway, the fact of the matter is that I'm not
> even convinced that we want it.  We will be getting good benefits, but
> the drawbacks are undeniable.

What drawbacks ?!  I have seen NOONE come up with any genuine
drawbacks that weren't the result of misunderstanding on their part.
The only drawbacks at all (apart from misunderstandings) have been
 - You have an entry for each user in /etc/group.
which is unbelievably trivial, and
 - "The sgid bit will confuse people."
which is weak and has been adequately refuted.

> My mere question is: if the benefits are
> so undeniable, why can't this change occur everywhere and not just
> Debian?

It can.  There's nothing stopping Slackware, TAMU, et al from
implementing exactly the scheme I describe.  Indeed, I would like to
see them do so.

In any case, the argument you state above is fallacious.  Just because
some other people have failed to do something doesn't mean it's a bad
idea.

>   If the Linux community (or a significant majority) felt that
> this is a good change and Linus agreed, could we have a low-level
> change in directory semantics?  I don't think POSIX defines anything in
> this area, but I haven't checked.

This is not a matter for the Debian list, more for the KERNEL channel
and/or col.development.  I'd be very interesting to hear your ideas -
in the right place.  Debian will have to work with the kernel as it is
now.

My proposal brings large benefits and has negligible costs.  It has
been tried and found useful independantly in several places.  It can
be implemented immediately.

====================

Bruce Perens writes:

> I'd like to call time on the uid=gid argument. I'm convinced this issue
> is not going to come to resolution through discussion here. Perhaps a
> demonstration would be more appropriate.

What is it you want me to demonstrate ?  That it works ?  Surely
that's obvious.  That it's useful ?  This is perhaps a little less
obvious if you've never worked on a shared project (especially an
informal one).

If people seriously doubt that sane use of the group write permission
is useful I can easily come up with several examples that I personally
have been involved with.

> The people who feel uid=gid is important are perfectly capable of
> building a package to implement it on top of a newly-installed release,
> including a script to change all permissions on every file in the
> distribution. Such a package can be installed on top of an existing
> Debian system with somewhat more difficulty than if the system came
> configured that way out of the box.

This is not a practical idea.  The scheme has to be installed from the
very start, because the permissions of every directory need to be
considered and perhaps changed.

What you are suggesting would mean that the upgrade kit would have to
be updated every time a new package was added to Debian.

> Please don't ask everyone to take it on faith that uid=gid is appropriate.

I'm not.  Strong arguments have been presented in its favour.

> And don't consider it overridingly important that you "save" every user
> by getting uid=gid into their system now.  Put together a package that
> implements it.  Show us how many users you get, and how they feel about it,
> and then you'll have the amunition to show that everybody's system should
> be configured that way.

Not practical.  See above.

Also, why does the default have to be broken ?

.. and later (in response to Matthew Birkholz) ...
> I proposed that you make a demonstration and show us some satisfied users
> as a means of arriving at a consensus when you were obviously not going
> to get a priori acceptance of your proposal. "Show me" is not an attack
> on your ideas. There are enough demonstrations of the status quo. Show
> us a concrete system that's better and some users who like it.

I forget who it was, but someone posted recently on this list saying
that their system had a very similar scheme in operation and that it
worked well.

The Cambridge University's Central Unix Service has user private
groups, for exactly the purpose have outlined.  It works well.

====================

Raul Deluth Miller writes:
> I think it's fairly obvious that we should provide a script to switch
> back and forth between the three configurations under discussion.  I
> can write a "modgrp" script which changes the current configuration,

It is not obvious at all.

How will it cope with packages that are added to Debian after you
wrote your script ?  It probably won't do it correctly.

> but I'm a little leary of re-writing something like adduser on the
> fly.  Can we have a configuration file that tells adduser how to act?

Urgh.  Why all this fuss ?  What is it that people have against my
proposal ?

> Are there any other distinctions we wish to make about groups?
> 
> Currently, I understand:
> bogus group (numeric id, but nothing in group -- can exist in
>   /etc/passwd, or can exist in filesystem [requires find]).
> orphaned groups (no ids assigned to that group)
> groups with no signon id (id has * in password field).
> system groups with signon id(s) [usually root, and sometimes sysadmin].
> user groups [this can include things like guest].

I'm sorry, I fail to see what you are talking about.

====================

Stephen White writes:
> ...
> And [the] directories [which would be setgid] is [sic] where all the
> action occurs. With the setgid scheme, virtually all activity will
> be conducted under BSD semantics anyway.

False.  Quite a lot of activity happens in /tmp and /usr/tmp, on my
system at least.

> ...
> Why bother with a weird system of permissions?

You're begging the question and using pejorative language: it's not `weird'.

>   Why bother with the added
> complexity? It's so much easier to just mount the drive with bsd semantics,
> wack in an additional line in the "adduser" script, and be done with it. Two
> small changes. Simple.

The reason not to do this has been explained by Matthew Hannigan and
myself in considerable detail.  You have not refuted our arguments.

--
Ian Jackson, at home  <ijackson@nyx.cs.du.edu> or <iwj10@cus.cam.ac.uk>
PGP2 public key available on server.  Urgent email: <iwj10@phx.cam.ac.uk>
2 Lexington Close, Cambridge, CB4 3LS, England;  phone: +44 223 64238

From debian-devel@pixar.com Mon Mar 21 06:23:38 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA24368; Mon, 21 Mar 94 06:23:35 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pihzl-0005pVa; Mon, 21 Mar 94 03:18 PST
Date: Mon, 21 Mar 94 03:18 PST
Message-Id: <m0piQuw-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Private groups & umask 002 proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

This message is a summary as I see it of the discussion regarding this
issue, including messages sent out by the listserver to me after about
midnight GMT on Saturday.  Anything sent later I haven't seen yet.

--- Here is what I am proposing:

  1. Each user gets their own private group.  Their gid = their uid
     and their group name is the same as their username.

  2. Each user is also a member of any additional "project" groups of
     which they need to be members.

  3. Both user home directories and project directories are mode 2775
     or 2770 and owned by the appropriate group.  On project
     directories the user ownership doesn't matter.  (2775 = drwxrwsr-x)
     This ensures that new files or directories created there will
     inherit both the correct group ownership and the setgid bit.

  4. The default umask is 002; if users and/or projects want to keep
     their files secret as well as safe they should chmod the
     appropriate directories to 2771 or 2770 (drwxrws--x or drwxrws---).

--- Here is why:

 This scheme solves a serious problem, namely that directories for
 group projects are quite simply unmanageable without it.

 I have often been in the position of having to do cp -r on large
 directory trees because I couldn't update the appropriate portions.
 Numerous times I have had to 'make clean' before I could 'make',
 because some of the '.o' files were unreadable and some were
 unwriteable.

 Having to switch umasks and default groups all the time is even more
 of a pain with a nice X workstation than it used to be with a vt220 on
 a serial line - now you have not only to remember which host and
 current directory an xterm is in, but what the group and umask are as
 well.  Changing all the time is a nightmare.  And as for one's Emacs -
 well, am I supposed to have one for each group/umask combination, or
 what ?

--- Summary of the debate so far:

Many non-arguments of various forms have been presented.

A couple of people requested clarifications, or details of how
particular problems might be addressed.  In each case these were
answered.

The only arguments I have seen against the proposal that weren't based
straightforwardly on fallacies, misconceptions or mistakes are:

 - You need to mess about with the /etc/group file to give
   everybody their own group.

   This seems to me to be an extraordinarily weak argument.  This is a
   minimal cost compared to the convenience benefits the proposal gets
   you.  In fact, my proposal is the thing that makes the /etc/group
   file important at all on a system.

 - People may `piss in their pants' as Matt put it when they
   see the `s' where they're used to seeing an `x' in their ls -l.

   This is even weaker, and can easily be solved by documentation.

 - It's "non-standard".

   This isn't true.  There is no "standard" way of doing this,
   precisely because this kind of decision is so often made by
   the local administrator or distribution provider.  It is perhaps a
   little unusual, however I have seen it done quite often - it is a
   solution that has been independantly reinvented several times at
   least to the knowledge of just the people who posted here on these
   lists, and in each case it has been found to work well.

 - It's unnecessary.

   I can personally testify that I have worked on several systems
   where it hadn't been done but would have been a great boon, and on
   others where it was implemented and was very useful.  These
   examples weren't bizarre local things, but straightforward
   informally managed projects usually involving software development.

   Given that it is definitely necessity for some people, in order to
   oppose it successfully one should show that it causes genuine
   problems for some of the people for whom it isn't necessary.

 I'm still waiting to see one worthwhile argument against my proposal.
 I don't expect to see one.


Ian.

From debian-devel@pixar.com Mon Mar 21 06:24:22 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA24382; Mon, 21 Mar 94 06:24:09 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pii0J-0005n2a; Mon, 21 Mar 94 03:18 PST
Date: Mon, 21 Mar 94 03:18 PST
Message-Id: <m0piREv-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: assurance that / is read-only before fsck
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Robert Sanders writes:
> Here's what I have in my rc.S now:
> ...
>         mount -n -o remount,ro /
>
> This obviously isn't perfect, but it at least tries to force the root
> directory to be read-only, and it's much less error prone than any
> other mothod I've seen.  At one point I had the script checking root's
> writability by echoing to a reserved file in /etc, but that's ugly,
> and the above solution will correct an improperly installed kernel.

I don't think this is safe.

I was under the impression that if you mount a fs read-write, then
read-only, and then read-write again, the kernel can buffer stuff
across the remount(s) in such a way that the filesystem can get
corrupted if you modify the fs while it is read-only.

I'd like to see someone knowledgeable about such things comment.

If this is true then perhaps attempting a test write to a file in /tmp
would be a better idea.

Ian.

From debian-devel@pixar.com Mon Mar 21 08:26:34 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA24765; Mon, 21 Mar 94 08:26:31 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pijuj-0005qGa; Mon, 21 Mar 94 05:21 PST
Date: Mon, 21 Mar 94 05:21 PST
Message-Id: <Pine.3.89.9403212221.A102-0100000@budge.apana.org.au>
Errors-To: bruce@pixar.com
Reply-To: charlieb@budge.apana.org.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: <charlieb@budge.apana.org.au>
To: debian-devel@pixar.com
Subject: Re: Guidelines
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

On Sun, 20 Mar 1994, Bill Mitchell wrote:

> On Sun, 20 Mar 1994, Charlie Brady wrote:
> 
> > On Thu, 17 Mar 1994, Bill Mitchell wrote:
> >[...] 
> > I think that Bill's reasoning is sound (apart from the "vi" to "emacs" 
> > change). The only problem that I have with it is that it might be
> > ambiguous, whereas a context diff is definitive.. Perhaps both
> 
> Definitive, but not comprehensive.  In the case of less-177, all the
> changes show up in files which are created by running the configure 
> script, and by doing further linux-specific edits to files created
> by the script.  The context diff reports the existance of these new 
> files, but not their contents, and not what linux-specific configuration 
> script responses and subsequent linux-specific file edits produced them.
> 
> > need to exist, the context diff so that so that anyone can easily rebuild
> > exactly the distributed binary, and the CHANGES file as a resource to a
> > subsequent developer.

Well that might depend on what type of context diff you have - it is
certainly possible to generate a context diff (to be used by patch of
course) containing the full text of any newly created files. I'm missing
the diff man page on this system, so can't quote the relevant options. 

So I repeat - a patch file is a definitive method of allowing anyone to 
easily build from source which will match exactly the distributed binary. 
The diff should be supplemented with a README such as Bill suggests which 
lists the steps taken by the developer to generate the diff.

On the subject of default editors, I agree that vi is a bit unusual to 
throw at newbies as a default, but then so is emacs. pico is very easy to 
use, joe a little less so. What do people think of us making some effort 
to add code wherever necessary so that the default editor is set by an 
environment variable - VISUAL or EDITOR for instance? The editor of 
choice can then be set at install time, or adduser time.

Charlie Brady * (W) charlieb@tplrd.tpl.oz.au * (H) charlieb@budge.apana.org.au
"Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
  but no simpler"   Einstein, A  | Fax: (02) 413 6868 Pacing Systems    \/  


From debian-devel@pixar.com Mon Mar 21 11:00:34 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA26341; Mon, 21 Mar 94 11:00:31 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pimJl-0005hZa; Mon, 21 Mar 94 07:55 PST
Date: Mon, 21 Mar 94 07:55 PST
Message-Id:  <9403211355.aa04310@s.s.ms.uky.edu>
Errors-To: bruce@pixar.com
Reply-To: kilroy@ms.uky.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: kilroy@ms.uky.edu
To: debian-devel@pixar.com
Subject: Re: Guidelines 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Your message dated: Sun, 20 Mar 94 20:25:00 PST
>
>
>I think that we should do a little vote on this....
>
>I have many users here that all we teach to them is Emacs...
>[stuff deleted]
>

Please dont start a flame war over this, like every other time
it has come up. I think both vi and emacs are hard to use..
I think pico is a good choice for a default editor. Anyone
that knows how to use vi or emacs, can probably learn to set an
EDITOR variable. Both my mom and two sisters learned how to use
pico w/o ANY help. This is an amazing feet that should deem it 
the default editor.

Of course, when accounts are created, they will inherit the default
scripts. In these scripts anyone wishing to have the editor that doesnt
win the vote can just set the EDITOR variable in these scripts and 
they wont notice a thing.

paul

--
#                       -Paul   (kilroy@ms.uky.edu)
exit 0

From debian-devel@pixar.com Mon Mar 21 11:17:33 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA26491; Mon, 21 Mar 94 11:17:31 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pimaC-0005lqa; Mon, 21 Mar 94 08:12 PST
Date: Mon, 21 Mar 94 08:12 PST
Message-Id: <9403211611.AA19205@bb29c.mdd.comm.mot.com>
Errors-To: bruce@pixar.com
Reply-To: mitchell@mdd.comm.mot.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
To: debian-devel@pixar.com
Subject: Re: Guidelines
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Charlie Brady said:

> [...]
> On the subject of default editors, I agree that vi is a bit unusual to 
> throw at newbies as a default, but then so is emacs. pico is very easy to 
> use, joe a little less so. What do people think of us making some effort 
> to add code wherever necessary so that the default editor is set by an 
> environment variable - VISUAL or EDITOR for instance? The editor of 
> choice can then be set at install time, or adduser time.

Many packages already do this.  My example for the CHANGES/README file thread
(less-177) uses the editor specified by the EDITOR environment variable.  The
change to emacs (which, incidentally was made in pre-debain changes for linux
which were present in the source package I obtained from tsx-11; and which I've
decided to change back to vi since the man pages in the packages had not been
changed to match this code change), was the choice of default editor to use
in the event that the EDITOR environment variable is left unspecified.

On adding code to a package beyond what is necessary to make that package
run on linux, I think that's a case-by-case issue.  For widely-used generic
packages (e.g., less, more, gcc, elvis, ...) , and for narrowly used packages
which have a clear central point of control (e.g., c2man, jgraph, ...),
It's best IMHO to work with the central maintainers to integrate bugfixes
and/or enhancements into the base package rather than spawning a maverick
version of the package.

From debian-devel@pixar.com Mon Mar 21 15:16:14 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA28824; Mon, 21 Mar 94 15:16:11 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0piqJB-0005h7a; Mon, 21 Mar 94 12:10 PST
Date: Mon, 21 Mar 94 12:10 PST
Message-Id: <199403212013.MAA11619@beagle.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: bruce@beagle.pixar.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: bruce@beagle.pixar.com
To: debian-devel@pixar.com
Subject: bug-list, GNATS, default editors, etc.
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Thanks, Matt Bailey, for volunteering. I agree we need someone who can
make a longer-term committment.

I'll look at GNATS today. Thanks, guys, for reminding me about it. 
I'd seen something on the net ages ago but had forgotten the name.

	Bruce

From debian-devel@pixar.com Mon Mar 21 15:28:50 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA28936; Mon, 21 Mar 94 15:28:47 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0piqVN-0006CSa; Mon, 21 Mar 94 12:23 PST
Date: Mon, 21 Mar 94 12:23 PST
Message-Id: <199403212025.MAA11653@beagle.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: bruce@beagle.pixar.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: bruce@beagle.pixar.com
To: debian-devel@pixar.com
Subject: default editors
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

I suggest that Debian support a symbolic link "/usr/bin/editor", which
is the default editor for all programs. Which editor that points to is
set up by the install scripts in response to a prompt, and can be easily
modified by the system admin at any time.

On the topic of default editors, having a single default, one that
is good for _beginners_ is a good idea, but beyond that why does anyone
care about the default? I take for granted that any decent application
would honor the value of my $EDITOR variable.

For those beginners, one of the "arrow keys move around, delete key
deletes the character under the cursor, typing is inserted to the right
of the cursor" editors would be best. Is that what "pico" is?

Then again, _real_ beginners should probably log in to the window system
and get visual-paradigm tools with buttons and menus and an easy window
manager. Maybe we should just run WINE and give them MS/Windows :-) .

					Bruce

From debian-devel@pixar.com Mon Mar 21 19:57:59 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01569; Mon, 21 Mar 94 19:57:54 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0piuho-0005qta; Mon, 21 Mar 94 16:52 PST
Date: Mon, 21 Mar 94 16:52 PST
Message-Id: <199403220051.AA10737@acme.gatech.edu>
Errors-To: bruce@pixar.com
Reply-To: gt8134b@acme.gatech.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: gt8134b@acme.gatech.edu (Robert Sanders)
To: debian-devel@pixar.com
Subject: Re: assurance that / is read-only before fsck
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Ian Jackson writes:
> Robert Sanders writes:
> > Here's what I have in my rc.S now:
> > ...
> >         mount -n -o remount,ro /
> >
> > This obviously isn't perfect, but it at least tries to force the root
> > directory to be read-only, and it's much less error prone than any
> > other mothod I've seen.  At one point I had the script checking root's
> > writability by echoing to a reserved file in /etc, but that's ugly,
> > and the above solution will correct an improperly installed kernel.
> 
> I don't think this is safe.

Well it might not be, but it SHOULD be.

> I was under the impression that if you mount a fs read-write, then
> read-only, and then read-write again, the kernel can buffer stuff
> across the remount(s) in such a way that the filesystem can get
> corrupted if you modify the fs while it is read-only.

What can happen is that blocks that were dirty before the remount to RO
won't get synced at the remount, so you've got dirty blocks hanging around.
That isn't really a problem, however; when *fsck tries to get a block
to read from or write to, it'll get the dirty block which specifies the real
state of the disk anyway.  After doing what it must to that block, the block
will be relegated to the buffer cache again until it's written out by
update(), bdflush(), or fsync().  There's no danger there, just business as
usual.

The danger comes in when the filesystem uses buffered devices and *fsck
uses raw devices.  The filesystem could keep dirty buffers in the
buffer cache, but since raw devices bypass the buffer cache, *fsck will
see an out-of-date copy when reading from disk.  *fsck will then modify
the block, write it out, and wind up accomplishing nothing, because when
the kernel flushes the corresponding buffer, it'll overwrite the block 
*fsck modified.  Linux doesn't support raw devices, and if it did, *fsck
would be safest to fsync() the buffered version of the device before fscking 
the filesystem.  Better yet, do_remount() might need to be modified to
fsync() the remounting device.

> I'd like to see someone knowledgeable about such things comment.

Was that a slight of my knowledge? :-)

> If this is true then perhaps attempting a test write to a file in /tmp
> would be a better idea.
 
Well, the thing is that a corrupted filesystem wouldn't necessarily benefit
from allocation activity.  That's why i recommended having a pre-allocated
file in /etc which gets 'touch'ed at startup.  If the 'touch' fails, you
know the fs is RW.  If it succeeds, there's not much harm it could do, as
no allocation takes place.  Note that a seriously confused filesystem 
might still be damaged.

If you're still worried about ghost buffers hanging around, my remount
suggestion could be changed to  "umount /" which is translated in-kernel to
this:

      fsync the root device
      remount the root filesystem read-only

which, raw devices or no, is safe, although less obvious.  It doesn't matter
to me, but something should be done.



From debian-devel@pixar.com Mon Mar 21 23:57:36 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02338; Mon, 21 Mar 94 23:57:32 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0piyRh-0009bPa; Mon, 21 Mar 94 20:52 PST
Date: Mon, 21 Mar 94 20:52 PST
Message-Id: <199403220449.OAA08876@extra.ucc.su.OZ.AU>
Errors-To: bruce@pixar.com
Reply-To: matth@ucc.su.oz.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Matthew Hannigan <matth@ucc.su.oz.au>
To: debian-devel@pixar.com
Subject: Re: Guidelines 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


> [ vi vs emacs for default editor ]

Definitely vi.  I use emacs a lot, but even if vi is a problem
for new users then the installer can override it after installation
(it would be nice to a have a friendlier editor installable and
pico sounds like a good candidate).

And you can always override the default with $EDITOR.

--	
	-Matt Hannigan

From debian-devel@pixar.com Tue Mar 22 00:22:16 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02468; Tue, 22 Mar 94 00:22:13 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0piypZ-0009ata; Mon, 21 Mar 94 21:16 PST
Date: Mon, 21 Mar 94 21:16 PST
Message-Id: <199403220516.VAA01255@mail.netcom.com>
Errors-To: bruce@pixar.com
Reply-To: jolomo@netcom.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: jolomo@netcom.com (Joe Morris)
To: debian-devel@pixar.com
Subject: Is crond sending mail?
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


I didn't see this in any bug reports, my crond doesn't seem to be
mailing any output.

I tried with and without "MAILTO=root"

here's some string output from crond:
-------------------------------
/usr/lib/sendmail -F"Cron Daemon" -odi -oem -or0s %s
From: root (Cron Daemon)
To: %s
Subject: cron for %s@%s said this
Date: %s
X-Cron-Cmd: <%s>
X-Cron-Env: <%s>
[%d] closing pipe to mail
mailed %d byte%s of output but got status 0x%04x
MAIL
-------------------------------

I didn't see any flags that might enable this in crontab or crond
manpages. Somebody advise me so I can find out if my backups
are taking place without doing a table of contents :)

Note for brain-farters: I have to deal with an older SCO release at
work and "crontab -r <file>" just deletes your current crontab!

                            Oops
-- 
        -joe        "Honey, they're in *everybody's* eggs" --firesigns

From debian-devel@pixar.com Tue Mar 22 00:37:31 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02557; Tue, 22 Mar 94 00:37:28 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0piz4L-0009bha; Mon, 21 Mar 94 21:32 PST
Date: Mon, 21 Mar 94 21:32 PST
Message-Id: <9403220531.AA27597@spiff.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: Is crond sending mail?
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Mon, 21 Mar 94 21:16 PST
   From: jolomo@netcom.com (Joe Morris)

   I didn't see any flags that might enable this in crontab or crond
   manpages. Somebody advise me so I can find out if my backups
   are taking place without doing a table of contents :)

I've upgraded cron to 3.0pl1 for 0.92.  I don't remember having a
problem with output mailing in 0.91, but this version is doing it just
fine.  The new version also has a `-e' option and several other nice
features.

I've also massively changed the way /var/adm backups are made (and the
whole crontab setup, actually...).  Instead of mailing and erasing (or
worse, erasing without a trace) these fairly important files, they are
now compressed and backed up to a special directory before they are
erased.  A specified number of these backups can be kept around at a
time; the script takes care of doing the backup and cycling the old
backups.

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Tue Mar 22 07:28:10 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA03128; Tue, 22 Mar 94 07:28:07 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pj5Tk-0009YSa; Tue, 22 Mar 94 04:22 PST
Date: Tue, 22 Mar 94 04:22 PST
Message-Id: <9403222024.A4627wk@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: stephen.white@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: stephen.white@adam.com.au
To: debian-devel@pixar.com
Subject: PRIVATE GROUPS
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


 
Ian Jackson writes:
 
 IJ> False.  Quite a lot of activity happens in /tmp and /usr/tmp,
 IJ> on my system at least.
 
This is a non-argument. It is completely irrelevant to the issue. The entire
purpose of the uid=gid argument is so people can share files with each other
_within their own (or project) directories_.
 
Waving a magic wand in the direction of /tmp is merely a trickery of
misdirection. It is not a valid argument, because it is not _relevant_.
 
Are project directories kept in /tmp? Are user directories kept in /tmp?
 
Why is there a continuing requirement to have SysV semantics within /tmp and
/usr/tmp? Can you explain how BSD managed all these years if SysV semantics are
such a requirement for /tmp?
 
The fact remains that uid=gid is merely a disguised BSD filing system.
 
Users will have their files under BSD semantics, and they will be sharing their
files under BSD semantics. There is no avoiding this realisation.
 
 SW> It's so much easier to just mount the drive with bsd semantics
 
 IJ> The reason not to do this has been explained by Matthew Hannigan
 IJ> and myself in considerable detail.  You have not refuted our
 IJ> arguments.
 
Incorrect. The one argument against mounting with BSD consituted of "What
happens if the admin sees the parameter in fstab and removes it?".
 
This is weaker than the weakest argument against your proposal.
 
It is _you_ who have not refuted my argument. I will ask the basic question
again.
 
Why is it so important to keep SysV semantics in relatively inactive parts of
the filing system?
 
To aid your comprehension, I will summarise and repeat.
 
uid=gid is so users can share access to files in each other's directories.
(note: /tmp and /usr/tmp are irrelevant). As this is the major activity of an
interactive system, it makes the system essentially BSD anyway.
 
Can you present any _valid_, _non-religious_, arguments showing why SysV
semantics need to be retained in other parts of the filing system?
 
Can you explain why the more complicated solution of setgid directories is
superior to mounting with BSD? Can you demonstrate where there are benefits to
setgid that BSD mounting wouldn't have, that makes it worth having a more
complicated filing system?
 
It would be more constructive if you refrained from the grandstanding arrogance
that your last message showed. There is no co-operativeness or good feeling to
be gained by sneering at the valid concerns of other people.
 
(As the obvious antagonism in my message will demonstrate)
 

From debian-devel@pixar.com Tue Mar 22 20:41:31 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA08181; Tue, 22 Mar 94 20:41:28 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjHrU-0009sPa; Tue, 22 Mar 94 17:36 PST
Date: Tue, 22 Mar 94 17:36 PST
Message-Id: <Pine.3.89.9403221122.B11705-0100000@sydte3>
Errors-To: bruce@pixar.com
Reply-To: charlieb@tplrd.tpl.oz.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Charlie Brady <charlieb@tplrd.tpl.oz.au>
To: debian-devel@pixar.com
Subject: Re: Bug tracking system
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


On Mon, 21 Mar 1994 imurdock@gnu.ai.mit.edu wrote:

>    Date: Sun, 20 Mar 94 19:49 PST
>    From: Charlie Brady <charlieb@tplrd.tpl.oz.au>
> 
>    Has anyone looked at "gnats" to see if it is suitable for automating
>    bug tracking. Here is some blurb from Gnu.announce:
> 
> [...]
> 
> I was going to ask the same question.  Has anyone used it?  It sounds
> like it just might fit our needs.

I haven't used it, but it was evaluated here, and rejected as not 
suitable for our needs. That doesn't mean it won't be suitable for Debian 
- I think it may be. But I'm told it is big - so someone with a 
reasonable amount of space and time will need to get it working. We don't 
have the source on-line, but we do have hard copy of some manuals.

 NAME
    GNATS - Problem Reporting Management System

 DESCRIPTION
    GNATS is a bug-tracking tool designed for use at a central support site.
    Software users who experience problems use electronic mail to 
    communicate problems to the maintainers of that software; GNATS 
    partially automates the tracking of these problems by:

    +  organizing problem reports into a database and notifying responsible
       parties of suspected bugs;

    +  allowing support personnel and their managers to edit, query and
       report on accumulated bugs; and

    +  providing a reliable archive of problems with a given program and a
       history of the life of the program by preserving its reported problems
       and their subsequent solutions.

 ........

It sounds quite interesting to me.

GNATS is Copyright Cygnus Support - Is there anyone doing Debian work 
from Cygnus, because I know there is Linux interest there.

Using something like GNATS will certainly help Debian Linux to avoid an 
SLS reputation.

Charlie Brady * (W) charlieb@tplrd.tpl.oz.au * (H) charlieb@budge.apana.org.au
"Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
  but no simpler"   Einstein, A  | Fax: (02) 413 6060 Pacing Systems    \/  


From debian-devel@pixar.com Tue Mar 22 20:47:28 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA08282; Tue, 22 Mar 94 20:47:26 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjHxG-0009saa; Tue, 22 Mar 94 17:41 PST
Date: Tue, 22 Mar 94 17:41 PST
Message-Id: <9403222244.AA21152@bb29c.mdd.comm.mot.com>
Errors-To: bruce@pixar.com
Reply-To: mitchell@mdd.comm.mot.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
To: debian-devel@pixar.com
Subject: Elvis 1.7 vs 1.8
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian's source package list contained the following entry:

drwxr-xr-x   3 root     root         2048 Mar  1 22:01 base/elvis-1.7/

I spoke up for this and a few other packages.  I'll be kitting them up
once a final set of guidelines for this is posted.

However, elvis is now at version 1.8pl1 (with pl2 in the works), though the
latest I've seen on the usual linux ftp sites is 1.7.  My plan is to kit up
the current 1.8 release, not 1.7.  I just thought I'd mention this ahead of
time in case anybody has a reason why I shouldn't do this.

From debian-devel@pixar.com Wed Mar 23 07:57:27 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA09909; Wed, 23 Mar 94 07:57:23 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjSPb-0009taa; Wed, 23 Mar 94 04:51 PST
Date: Wed, 23 Mar 94 04:51 PST
Message-Id: <m0pjDvp-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Private groups
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Stephen White writes (BTW, there's no need to shout):
> Ian Jackson writes:
>  IJ> False.  Quite a lot of activity happens in /tmp and /usr/tmp,
>  IJ> on my system at least.
>  
> This is a non-argument. It is completely irrelevant to the issue. The entire
> purpose of the uid=gid argument is so people can share files with each other
> _within their own (or project) directories_.

I see that you have `conveniently' elided the part of your message I
was responding to:

> [Ian Jackson writes:]
> > Stephen White writes:
> > > ...
> > > And [the] directories [which would be setgid] is [sic] where all the
> > > action occurs. With the setgid scheme, virtually all activity will
> > > be conducted under BSD semantics anyway.
> > 
> > False.  Quite a lot of activity happens in /tmp and /usr/tmp, on my
> > system at least.

You claimed that all the action occurs in directories which would be
setgid, and implied that only project and user home directories would
be.

Your claim was false, so the argument you based on it was unsound.

I shall now deal with the rest of your posting.

> Why is there a ... requirement to have SysV semantics within /tmp and
> /usr/tmp?

If we use a umask of 002 or some such and mount /tmp &c with BSD
semantics it will be necessary to make /tmp group-owned by a group
such as `root' or `system' that no unpriveliged users are members of.
This is required as all files created in /tmp will otherwise be
writeable by the unpriveliged users of the group which owns /tmp.

Therefore, files in /tmp will be owned by this `system' group rather
than the groups of the users who created the files.

Now, in general, if we adopt the private groups scheme the most
important part of the ownership of a file will no longer be the user
ownership but the group ownership, as that is what will control write
access to most files, and also read access to most private files.

My first argument in this message against BSD semantics in /tmp is
that this violates the general rule in my previous paragraph.  If this
is done some files will have their access controlled by the group
ownership and some by the user ownership.

My second argument in this message against BSD semantics is that it is
generally less expected than System V semantics.  When using SysV
semantics the setgid bit gives you a clear indication that something
is happening to the group ownerships around the directory.  When using
BSD semantics this will be less clear, and the behaviour will
therefore be further from that which might be expected.

> Can you explain how BSD managed all these years if SysV semantics are
> such a requirement for /tmp?

Neither of the two arguments I make above apply in a traditional BSD
system with a umask of 022 or similar.  The first argument doesn't
apply because group ownership is generally irrelevant on such a system
- access is controlled by user ownership.  The second argument doesn't
apply for this reason as well, and also because `ls' doesn't show the
group ownership by default on BSD, thus hiding the unexpected
behaviour (out of sight, out of mind).

> The fact remains that uid=gid is merely a disguised BSD filing
> system.

uid=gid has nothing to do with it.

>  SW> It's so much easier to just mount the drive with bsd semantics
>  
>  IJ> The reason not to do this has been explained by Matthew Hannigan
>  IJ> and myself in considerable detail.  You have not refuted our
>  IJ> arguments.
>  
> Incorrect. The one argument against mounting with BSD consituted of "What
> happens if the admin sees the parameter in fstab and removes it?".

You have obviously not been reading the list.

In <199403120410.OAA27987@extra.ucc.su.OZ.AU> on Fri, 11 Mar 94 at
20:14 PST, Matthew Hannigan <matth@ucc.su.oz.au> wrote on the
debian-devel list:

] I strongly agree.  If you use the bsd _mount_ options then:
]
]         1. You can't get back the V7 semantics back for
]                 individual directories.
]         2. You're changing things for users without making
]                 the change manifest.  (i.e. it seems as if
]                 you're trying to sneak a change past the users)
]         3. It can be too easily turned off by an administrator
]                 (Users start to rely on the bsds semantics then
]                 one day some admin looks at fstab and thinks,
]                 hey what does this do?  I think I'll take it
]                 out (or not remember to put it in when modifying it))

In <m0pfopW-0002dGC.ijackson@nyx.cs.du.edu> on Mon, 14 Mar 94 at
10:49 PST, I wrote on the debian-devel list:

] 4. It violates the principle of least surprise.  Files will be created
] (with a umask of 002, remember) with odd group ownership for no
] readily apparent reason.  The same could be said of setgid, but the
] g+s bit in the directory permissions is much more visible and is the
] kind of thing that people would believe might have this effect.
]
] This could be seen as another facet of Bradley Bosch's argument and
] Matthew Hannigan's reason 1 (that using BSD you can't get the V7
] semantics back for individual directories).  Using setgid allows
] selection on a directory-by-directory level; whereas using bsd
] semantics allows selection on a system-by-system level.
]
] The question is really which is most likely to be required, and how
] much effort it is to work around if one needs something that's not
] provided.
]
] I believe that we're much more likely to want to turn off this feature
] for individual directories (/tmp and /usr/tmp come to mind
] immediately).  In practice, I don't think that many sysadmins would
] bother turning it off even if we made it easy by mounting everything
] bsd-style.

These arguments have not been refuted.

I think you would benefit from reading the alt.atheism FAQ file on how
to construct a logical argument.  It can be found on rtfm.mit.edu in
/pub/usenet/news.answers/atheism/logic.

Ian.

From debian-devel@pixar.com Wed Mar 23 08:27:36 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA10176; Wed, 23 Mar 94 08:27:31 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjSsl-0009tca; Wed, 23 Mar 94 05:22 PST
Date: Wed, 23 Mar 94 05:22 PST
Message-Id: <9403231319.AA26062@server.et-inf.fho-emden.de>
Errors-To: bruce@pixar.com
Reply-To: tobias@server.et-inf.fho-emden.de
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: tobias@server.et-inf.fho-emden.de (Peter Tobias)
To: debian-devel@pixar.com
Subject: Private groups ...
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Hi!

Why not ask at install time whether someone wants to use private groups or not.
It should be possible to add a few lines to the install or setup script
that will do the configuration (umask, adduser script etc.) for the normal
groups setup or the private groups.


Peter

-- 
 Peter Tobias                                EMail:
 Fachhochschule Ostfriesland                 tobias@server.et-inf.fho-emden.de
 Fachbereich Elektrotechnik und Informatik   tobias@perseus.fho-emden.de
 Constantiaplatz 4, 26723 Emden

From debian-devel@pixar.com Wed Mar 23 19:40:53 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA15942; Wed, 23 Mar 94 19:40:50 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjdOL-0006G2a; Wed, 23 Mar 94 16:35 PST
Date: Wed, 23 Mar 94 16:35 PST
Message-Id: <199403240037.QAA06407@beagle.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: bruce@beagle.pixar.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: bruce@beagle.pixar.com
To: debian-devel@pixar.com
Subject: using GNATS for Debian
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

It looks as if GNATS will work for tracking Debian bugs. I'll be
experimenting with it here for a while.

	Bruce

From debian-devel@pixar.com Thu Mar 24 00:52:36 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA17755; Thu, 24 Mar 94 00:52:21 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjiFo-0005hEa; Wed, 23 Mar 94 21:46 PST
Date: Wed, 23 Mar 94 21:46 PST
Message-Id: <9403240545.AA23781@spiff.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: user/group -- my compromise proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ok.  I've been following the debate silently since it began, and I
think that both sides have valid arguments.  What follows is how I
plan to implement it in 0.92, so please comment ASAP.  I want to get
0.92 out soon and don't want to delay much longer.  But I also agree
with Ian Jackson that if we're going to do it we must do it _now_, so
please comment before it's too late...

First of all, my experimentation has led to the following changes in
the default Debian system.  These make the task of kernel upgrading
and local software installation much easier (and without the need to
use the root account):

* Any users in the `disk' and `src' groups may compile and install a new
  kernel image (being a member of the `disk' group is necessary for the
  use of lilo).  The kernel image has been moved to /boot and there is a
  symlink from /vmlinux -> /boot/vmlinux.  The directory permissions are
  as follows:

  drwxrwsr-x   2 root     src          1024 Mar 23 00:39 /boot/
  drwxrwsr-x   4 root     src          1024 Mar 23 00:11 /usr/src/linux

* Any users in the `staff' group may compile and install software
  under /usr/local.  The directory permissions are as follows:

  drwxrwsr-x   4 root     staff        1024 Mar 24 00:31 /usr/src/

  [ This is /usr/local. ]

  drwxrwsr-x  12 root     staff        1024 Mar 20 23:43 ./
  drwxr-xr-x  16 root     root         1024 Mar 22 23:33 ../
  drwxrwsr-x   2 root     staff        1024 Mar 23 00:43 bin/
  drwxrwsr-x   2 root     staff        1024 Mar 22 22:50 doc/
  drwxrwsr-x   2 root     staff        1024 Mar 22 22:50 etc/
  drwxrwsr-x   4 root     staff        1024 Mar 22 22:50 games/
  drwxrwsr-x   2 root     staff        1024 Mar 22 22:50 include/
  drwxrwsr-x   2 root     staff        1024 Mar 23 00:47 info/
  drwxrwsr-x   3 root     staff        1024 Mar 14 16:52 lib/
  drwxrwsr-x   2 root     staff        1024 Mar 22 22:50 man/
  drwxrwsr-x   2 root     staff        1024 Mar 23 00:44 sbin/
  drwxrwsr-x   6 root     staff        1024 Mar 23 23:56 src/

  [...]

Note that /bin, etc. will remain the same permission-wise (755,
root.bin) because adding software to these directories should be
discouraged.

Regarding project groups and the user/group debate, I am adding an
option to adduser that will do the following:

  * create a GID = UID and make it the user's default group
  * create a home directory for the user of mode 2775 and owner UID.GID
  * change the umask in the _user's_ .profile to 002.
  * add the user to any groups specified

Note that the _system_ umask (the one in /etc/profile) will remain
022.  This will allow only those users requiring special group access
to use the new scheme by overriding the default with 002.  Not every
user will need such access, but those who do (or system administrators
who want their system to use such a scheme) may easily do so.

I hope this will make everyone happy.  The methods are not mutually
exclusive and can indeed co-exist.

(Would it be wise to start the user UIDs at 500 instead of 100?  I
don't forsee much of a conflict after 500, but I can at 100...)

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Thu Mar 24 01:48:14 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA17943; Thu, 24 Mar 94 01:48:12 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjj7r-000A1ea; Wed, 23 Mar 94 22:42 PST
Date: Wed, 23 Mar 94 22:42 PST
Message-Id: <Pine.3.89.9403240115.A2432-0100000@vani>
Errors-To: bruce@pixar.com
Reply-To: mbailey@cps201.cps.cmich.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Matt Bailey <mbailey@cps201.cps.cmich.edu>
To: debian-devel@pixar.com
Subject: Re: user/group -- my compromise proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

I like the proposal alot except can users be added by anyone other than 
root? like say if there was three admins can anyone add a user with out 
know the root passwd?


--
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||                                ||  root@stimpy.cps.cmich.edu      ||
|| Matthew S. Bailey              ||  mbailey@cps201.cps.cmich.edu   ||
|| 109 Merrill Hall               ||  32bdzwc@cmuvm.csv.cmich.edu    ||
|| Central Michigan University    |||||||||||||||||||||||||||||||||||||
|| Mt. Pleasant  MI  48858        ||  Get rid of MS-DOG and switch   ||
|| (517) 774-4141                 ||  To a real Operating System     ||
||                                ||         L I N U X!!             ||
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||








From debian-devel@pixar.com Thu Mar 24 05:21:12 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA18098; Thu, 24 Mar 94 05:21:08 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjmRv-000A2Pa; Thu, 24 Mar 94 02:15 PST
Date: Thu, 24 Mar 94 02:15 PST
Message-Id: <m0pjZbX-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Private groups ...
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Peter Tobias writes:
> Why not ask at install time whether someone wants to use private
> groups or not.  It should be possible to add a few lines to the
> install or setup script that will do the configuration (umask,
> adduser script etc.) for the normal groups setup or the private
> groups.

Please read the the messages that are posted before trying to respond.

Nearly two weeks ago I wrote:
] It has to be the default because retrofitting it is an incredible pain
] in the backside.  You can't ask users to choose whether they want it
] or not at install time because they won't understand the question.

This is still true.

Additionally, there are already enough questions in the installation
procedure without adding yet another, especially one that has
virtually no benefit.

Ian.

From debian-devel@pixar.com Thu Mar 24 06:19:25 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA18190; Thu, 24 Mar 94 06:19:14 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjnM8-000A3Ca; Thu, 24 Mar 94 03:13 PST
Date: Thu, 24 Mar 94 03:13 PST
Message-Id: <199403241112.VAA11299@extra.ucc.su.OZ.AU>
Errors-To: bruce@pixar.com
Reply-To: matth@ucc.su.oz.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Matthew Hannigan <matth@ucc.su.oz.au>
To: debian-devel@pixar.com
Subject: Re: Private groups ... 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


iwj10@cus.cam.ac.uk (Ian Jackson) writes:
> Nearly two weeks ago I wrote:
> ] It has to be the default because retrofitting it is an incredible pain
> ] in the backside.  You can't ask users to choose whether they want it
> ] or not at install time because they won't understand the question.
> 
> This is still true.
> 
> Additionally, there are already enough questions in the installation
> procedure without adding yet another, especially one that has
> virtually no benefit.

And if you the installer really must have the "old" ways back, then
it easier to go that way than from the "old" way to this scheme.

But you won't want to do that.

--
	-Matt Hannigan

From debian-devel@pixar.com Thu Mar 24 07:35:49 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA18298; Thu, 24 Mar 94 07:35:47 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjoYE-000A5Ya; Thu, 24 Mar 94 04:30 PST
Date: Thu, 24 Mar 94 04:30 PST
Message-Id: <9403241228.AA26612@spiff.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: user/group -- my compromise proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Wed, 23 Mar 94 22:42 PST
   From: Matt Bailey <mbailey@cps201.cps.cmich.edu>

   I like the proposal alot except can users be added by anyone other than 
   root? like say if there was three admins can anyone add a user with out 
   know the root passwd?

No.  root is still the only user that can add users.

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Thu Mar 24 09:10:05 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA18620; Thu, 24 Mar 94 09:09:59 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjq1K-000A79a; Thu, 24 Mar 94 06:04 PST
Date: Thu, 24 Mar 94 06:04 PST
Message-Id: <199403241403.AA15402@masi.ibp.fr>
Errors-To: bruce@pixar.com
Reply-To: Remy.Card@masi.ibp.fr
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Remy.Card@masi.ibp.fr (Remy CARD)
To: debian-devel@pixar.com
Subject: Re: user private groups and a src group
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


	Hi,

	I am sorry that waste more bandwith by replying to this thread but
Mr Jackson does not seem to accept that other people may have other opinion
so I have to reply to explain again.

Ian Jackson writes:

> ====================
> 
> Remy Card writes:
> >          [ Source code control is a good thing, therefore ]
> >         1. write access to a common set of files by a development team
> >            is not needed (and not even desirable) to achieve a project
> >            with efficiency,
> 
> Not every shared project has many people all updating the same source
> files all the time, and therefore not every project needs to use RCS
> or an equivalent.

	Well, this depends how you understand `many'.  IMO, the word `many'
can be used as soon as there is more than one developer.

> And, as Matthew Birkholz has pointed out, RCS doesn't work unless the
> users using it have shared access to the repository.

	No, this is wrong.  The users need to have shared write access on
the directories in the repository if you use RCS.  If you use CVS, you don't
have to care since CVS sets group write access on directories in the
repository.

> On very few of the shared projects I have worked on has it been
> necessary to use source code control.  Perhaps the projects I work on
> have been less formally managed than others, but they prove the
> existence (frequently!) of projects where this is the case.

	Of course, unmanaged projects exist, but do you think that we have to
promote them?  I'd prefer to see the use of version control system promoted
for shared projects instead of suggesting people to modify the same set of
files without any coordination.

> >[rest of argument deleted as it doesn't follow if I refute the premise]
> >
> >         Of course, I'll be glad to hear about conter examples (important
> > ptojects which cannot be achieved with the help of a version control
> > system and which require a change in the uid and gid attribution).
> 
> I have answered most of this above.

	I'm sorry but you did not answer.  I still have to see you describe
a big project which cannot be achieved with the help of a version control
system.

> However I'll also say that often
> a version control system can be a help rather than a hindrance; even
> if it were able to solve the same problem as the private groups
> proposal (which it isn't) one shouldn't assume that it is the right
> solution for everybody.

	The use of a version control system can solve the problem.  Let's
state it again :
	1. with a version control system, users do not have write access to
	   shared files stored in the repository,
	2. with a version control system, users have to checkout the files and
	   work on a copy of the development files,
	3. users can change the working copies, test the changes, debug them
	   and commit them (checkin the files) when they are satisfied,
	4. since users work on their own copies of the files, they do not need
	   to have a permissive umask (i.e. 002),
	5. thus, there is no need for the proposal if you accept the use of
	   version control system.

	If you don't use any version control system, several risks exist:
	1. user A and B edit the same file, A writes his changes, the B writes
	   out his own changes and erases modifications made by A,
	1. user A has several files to change to add a new feature, A makes
	   changes in a few files, B starts using the shared files before
	   A completes his changes thus using an inconsistent set of files.

	Please note that I don't claim that version control systems are the
only solution or even the best one.  I just suggest that their use should be
considered.

> ====================
> 
> Glen Reesor writes:
> > These two quotes bring to mind an issue I haven't seen mentioned yet--
> > that of sharing filesystems via NFS with machines that do *not* use
> > this uid=gid method.  Won't it be a major pain to align the two
> > machines' group and passwd files??
> 
> No more than it is anyway.  In this case the uid=gid can be abandoned
> quite easily.  You simply change the default umask to 022 and copy the
> shared passwd and group files verbatim onto your system.

	So, your proposal does not work in a networked environment where a
PC running Linux needs to interact with NFS servers which use the de-facto
standard way of attributing uid and gid?  If so, this is a big restriction.

> The setgid bit on each directory can be left alone, as it then ceases
> to have any meaningful effect on the permissions of files created
> there.

	You seem to consider that the group inheritance is only useful for
sharing write access to files.  I do not agree.  At our university, we use
this to allow read access to some files for some users belonging to the
same group (with umask = 027).  Even if a shared write access is not needed,
groups can still be use to share read access.

> ====================
> 
> Paul Vojta writes:
> > 
> > This I don't understand.  What is the value of having gid=uid?  
> 
> However, having gid==uid is a useful feature to add to my proposal
> because it enhances consistency and therefore makes administration
> easier.  It would also make it possible to (for example) go for
> uid/gid unification in the kernel (cf the Hurd).

	Can you please explain this `uid/gid unification in the kernel' ?  As
far as I know (and I am a kernel developer so I suppose that I should now), the
kernel only uses uid and gid to test for access permissions on files and on
processes (e.g. the kill system call).  The kernel itself does not care about
the attribution of uid/gid.  The only literal test made on uids is the
macro `suser' which tests if the effective uid of the current process is 0
(i.e. the current process runs with root priviledges).

> > Regarding the kernel example, it is a dangerous practice, IMHO, to allow
> > people to modify the kernel but not give them root access.  They would then
> > have both the ability and the incentive to introduce security holes into
> > the kernel.
> 
> Do you always do your kernel compilations as `root' ?  I don't like
> to.  It makes it more likely that I will (for example) accidentally
> wipe out half my system with a misplaced `rm'.

	I think that you misunderstood Paul's words.  Paul was meaning that
letting users change the kernel source files may be very dangerous.  If these
users introduce bugs in the kernel, these bugs will be activated next time
the administrator compiles the new kernel and boots it.

> Also, I'm not necessarily suggesting that the group of people with
> write access to the kernel source should be greater than those who can
> su to root with no password.

	What's that?  Does Debian contain a group that is allowed to su root
without any password?  If so, this may open a security risk since this may be
easier to guess one of N passwords than the single root password to get
superuser priviledges.

	I prefer a scheme where an admin group exists (call it the name you
want, I don't care) and only members of this group are allowed to su root but
they have to know the root password.  This is the way BSD works.  OK, the su
command from GNU does not implement this feature but this should be quite easy
to add it.

> > So why don't we keep the default debian behavior as it is currently, and
> > allow an option in adduser (and /etc/defaults/adduser or wherever it is)
> > to use Ian's system?
> 
> Why does the default have to be broken ?

	This sentence is pejorative.  Why don't you say `Why does the default
have to be something that I consider to be broken' ?

> ====================
> 
> Carl Powers writes:
> > 
> > The difference between 'vast majority' and 'all' is 'some'.  Is that 'some'
> > of less importance than 'those few' who would benefit from such a scheme?
> 
> You have not shown how my proposal harms the `some'.  I don't believe
> my scheme will significantly inconvenience *anyone* (well, anyone
> reasonable).

	You are offensive again by implying that only unreasonable persons
may disagree with you.

> Alternatively, as Matthew Hannigan suggests, you can just change the
> umask and leave the /etc/group alone.  After all, if your umask is 022
> you're not using the groups anyway and the contents of /etc/group will
> make little difference.

	This is wrong.  Groups can be used to control shared read access on
files as I have explained above.

> In every case where I have had people sharing an area of filespace on
> a Unix system exactly one of the following two things was true:
> 
>  1. We had umask 002 and user private groups.
>  2. There were continual problems with setup files not running
>     correctly, files having the wrong permissions, security holes,
>     etc. etc. etc.  It was a real pain.

	How about adding a third thing:
  3. We were using a version control system and we had no problem accessing
     the common repository.  Moreover, the version control system was very
     useful to detect and correct conflicts.

> ====================
> 
> Daniel Quinlan writes:
> 
> > I'd rather it was just the default Linux behavior, but it isn't going
> > to happen.  I wish that we didn't have to even think about mucking
> > around with /etc/group.
> 
> The phrase `mucking around' is unjustifiably pejorative.

	Hey, Mr Jackson, don't you think that the most offensive mail comes
from you ?  Your mails contain lots of insults for people who disagree with
you:
	- every argument against your proposal is said to be a non argument,
	- you say that every reasonable person should agree with you implying
	  that every opponent to your proposal is not reasonable,
	- you state that every other opinion `is broken',
	- and so on ...

	Sometimes, you look to me like Bill Jolitz and the *BSD folks who
cannot accept that someone does not fully agree with them...

> > My mere question is: if the benefits are
> > so undeniable, why can't this change occur everywhere and not just
> > Debian?
> 
> It can.  There's nothing stopping Slackware, TAMU, et al from
> implementing exactly the scheme I describe.  Indeed, I would like to
> see them do so.

	Hmm, why do you restrict you to Linux distributions?  Go ahead, Mr
Jackson, extend your proposal to other Unix distributions.  Why don't you
propose that your private groups idea be implemented in the BSD distributions
for example?

> In any case, the argument you state above is fallacious.  Just because
> some other people have failed to do something doesn't mean it's a bad
> idea.

	I agree with you here.  Simply saying that nobody has implemented it
is not enough to say that it's a bad idea.  But, I think that one should
consider other people's solution too and it seems to me that you did not
bother investigating other's solution before submitting your proposal.  Why
don't you ask existing development teams how they work.  Ask CMU, ask the FSF,
ask the BSD folks, ask the Kerberos team, ask the X Consortium about their
solutions, try to understand them and consider them.

> >   If the Linux community (or a significant majority) felt that
> > this is a good change and Linus agreed, could we have a low-level
> > change in directory semantics?  I don't think POSIX defines anything in
> > this area, but I haven't checked.
> 
> This is not a matter for the Debian list, more for the KERNEL channel
> and/or col.development.  I'd be very interesting to hear your ideas -
> in the right place.  Debian will have to work with the kernel as it is
> now.

	I strongly disagree.  I think that people can discuss some needed
extensions to the kernel before submitting a proposal to the KERNEL channel
and/or the filesystem developers.  After all, if an extension is needed for
Debian, it can be discussed on a this mailing list and submitted to the
kernel developers if/when there is a consensus on it.

> ====================
> 
> Bruce Perens writes:
> 
> > I'd like to call time on the uid=gid argument. I'm convinced this issue
> > is not going to come to resolution through discussion here. Perhaps a
> > demonstration would be more appropriate.
> 
> If people seriously doubt that sane use of the group write permission
> is useful I can easily come up with several examples that I personally
> have been involved with.

	Please describe them.  You always say `I can easily give real examples'
but you never explain them.  Can you please describe them to serve as a basis
for future discussion.

> > The people who feel uid=gid is important are perfectly capable of
> > building a package to implement it on top of a newly-installed release,
> > including a script to change all permissions on every file in the
> > distribution. Such a package can be installed on top of an existing
> > Debian system with somewhat more difficulty than if the system came
> > configured that way out of the box.
> 
> This is not a practical idea.  The scheme has to be installed from the
> very start, because the permissions of every directory need to be
> considered and perhaps changed.

	Hmmm, I don't understand.  I thought that permissions had to be changed
on user and project directories.  Why should we change the permissions on
the system and application directories?

> Also, why does the default have to be broken ?

	Oh no!  Not again!

> .. and later (in response to Matthew Birkholz) ...
> > I proposed that you make a demonstration and show us some satisfied users
> > as a means of arriving at a consensus when you were obviously not going
> > to get a priori acceptance of your proposal. "Show me" is not an attack
> > on your ideas. There are enough demonstrations of the status quo. Show
> > us a concrete system that's better and some users who like it.
> 
> I forget who it was, but someone posted recently on this list saying
> that their system had a very similar scheme in operation and that it
> worked well.

	Yes, and I can say that projects I have been involved in have been
well managed (with version control systems) and everything works well too.

> ====================
> 
> Raul Deluth Miller writes:
> > I think it's fairly obvious that we should provide a script to switch
> > back and forth between the three configurations under discussion.  I
> > can write a "modgrp" script which changes the current configuration,
> 
> It is not obvious at all.
> 
> How will it cope with packages that are added to Debian after you
> wrote your script ?  It probably won't do it correctly.

	Again, why do you want to extend the proposal to system and application
directories?  Allowing a group of users to modify these directories may create
security risks.

> > but I'm a little leary of re-writing something like adduser on the
> > fly.  Can we have a configuration file that tells adduser how to act?
> 
> Urgh.  Why all this fuss ?  What is it that people have against my
> proposal ?

	Don't be paranoid.  Some people may have other solutions to the same
problem and you should be prepared to a debate when you propose a change.

> ====================
> 
> Stephen White writes:
> > ...
> > And [the] directories [which would be setgid] is [sic] where all the
> > action occurs. With the setgid scheme, virtually all activity will
> > be conducted under BSD semantics anyway.
> 
> False.  Quite a lot of activity happens in /tmp and /usr/tmp, on my
> system at least.

	Hu?  You store project and user directories in /tmp and/or /usr/tmp?

> >   Why bother with the added
> > complexity? It's so much easier to just mount the drive with bsd semantics,
> > wack in an additional line in the "adduser" script, and be done with it. Two
> > small changes. Simple.
> 
> The reason not to do this has been explained by Matthew Hannigan and
> myself in considerable detail.  You have not refuted our arguments.

	The only argument against mounting filesystem with BSD semantics seems
to be `what happens if the administrator removes the bsd option from
/etc/fstab.  Using setgid directories opens the same risks: what happens if
the administrator or the directory owner removes the setgid bit?

	BTW, it seems to me that this thread gives me the opportunity to
suggest the changes in the default behavior for directory semantics.  As I
said before in this list, I am willing to change the ext2fs default behavior
to use BSD semantics and implement it in other filesystems.  I will contact
other filesystem developers to check if they have objections and then I will
send a proposal on the KERNEL channel.

> --
> Ian Jackson, at home  <ijackson@nyx.cs.du.edu> or <iwj10@cus.cam.ac.uk>
> PGP2 public key available on server.  Urgent email: <iwj10@phx.cam.ac.uk>
> 2 Lexington Close, Cambridge, CB4 3LS, England;  phone: +44 223 64238

--
Remy Card
card@masi.ibp.fr

"The shame was on the other side, we can be heroes for ever and ever"

From debian-devel@pixar.com Thu Mar 24 10:03:00 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA19163; Thu, 24 Mar 94 10:02:57 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjqqe-000A8fa; Thu, 24 Mar 94 06:57 PST
Date: Thu, 24 Mar 94 06:57 PST
Message-Id: <199403241456.AA07381@istwok.ods.com>
Errors-To: bruce@pixar.com
Reply-To: david@istwok.ods.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: David Engel <david@istwok.ods.com>
To: debian-devel@pixar.com
Subject: Re: user/group -- my compromise proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

> Ok.  I've been following the debate silently since it began, and I
> think that both sides have valid arguments.  What follows is how I
> plan to implement it in 0.92, so please comment ASAP.  I want to get
> 0.92 out soon and don't want to delay much longer.  But I also agree
> with Ian Jackson that if we're going to do it we must do it _now_, so
> please comment before it's too late...

This all looks good, Ian, except for the one thing noted below.

> * Any users in the `disk' and `src' groups may compile and install a new
>   kernel image (being a member of the `disk' group is necessary for the
>   use of lilo).  The kernel image has been moved to /boot and there is a
>   symlink from /vmlinux -> /boot/vmlinux.  The directory permissions are
>   as follows:
> 
>   drwxrwsr-x   2 root     src          1024 Mar 23 00:39 /boot/
>   drwxrwsr-x   4 root     src          1024 Mar 23 00:11 /usr/src/linux

I feel the group of /boot should be `disk' or `root'.  If you need to
be a member of group `disk' to use lilo, you should also need to be a
member of group `disk' to overwrite *anything* in /boot.

David
-- 
David Engel                        Optical Data Systems, Inc.
david@ods.com                      1101 E. Arapaho Road
(214) 234-6400                     Richardson, TX  75081

From debian-devel@pixar.com Thu Mar 24 10:44:41 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA19630; Thu, 24 Mar 94 10:44:38 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjrUz-0006Bxa; Thu, 24 Mar 94 07:39 PST
Date: Thu, 24 Mar 94 07:39 PST
Message-Id: <9403241538.AA28058@spiff.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: user/group -- my compromise proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Thu, 24 Mar 94 06:57 PST
   From: David Engel <david@istwok.ods.com>

   > * Any users in the `disk' and `src' groups may compile and install a new
   >   kernel image (being a member of the `disk' group is necessary for the
   >   use of lilo).  The kernel image has been moved to /boot and there is a
   >   symlink from /vmlinux -> /boot/vmlinux.  The directory permissions are
   >   as follows:
   > 
   >   drwxrwsr-x   2 root     src          1024 Mar 23 00:39 /boot/
   >   drwxrwsr-x   4 root     src          1024 Mar 23 00:11 /usr/src/linux

   I feel the group of /boot should be `disk' or `root'.  If you need to
   be a member of group `disk' to use lilo, you should also need to be a
   member of group `disk' to overwrite *anything* in /boot.

That does make more sense.  I'll make the change when I get home.

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Thu Mar 24 10:56:05 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA19755; Thu, 24 Mar 94 10:56:01 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjrfz-0005pRa; Thu, 24 Mar 94 07:50 PST
Date: Thu, 24 Mar 94 07:50 PST
Message-Id: <9403241548.AA28115@spiff.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: user private groups and a src group
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Thu, 24 Mar 94 06:04 PST
   From: Remy.Card@masi.ibp.fr (Remy CARD)

   > Also, I'm not necessarily suggesting that the group of people with
   > write access to the kernel source should be greater than those who can
   > su to root with no password.

	   What's that?  Does Debian contain a group that is allowed
   to su root without any password?

Most certainly not. :)

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Thu Mar 24 14:20:30 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA21309; Thu, 24 Mar 94 14:20:27 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjurm-0005qea; Thu, 24 Mar 94 11:14 PST
Date: Thu, 24 Mar 94 11:14 PST
Message-Id: <9403241753.AA70125@whale.st.usm.edu>
Errors-To: bruce@pixar.com
Reply-To: cubranic@whale.st.usm.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: cubranic@whale.st.usm.edu (Davor Cubranic)
To: debian-devel@pixar.com
Subject: Re: Guidelines
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Why not use joe instead of pico as a 'user-friendly' editor?  It
is similar to wordstar/Borland editors, so I'd imagine a lot of
people migrating from DOS world would be familiar with it.  It
is a little bit bigger than pico, but not much, about 60K on
our RS6000 station (I'm not sure what the exact sizes are on
linux, but I'd guess the relation is similar).

Davor Cubranic
cubranic@whale.st.usm.edu

From debian-devel@pixar.com Thu Mar 24 14:30:27 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA21466; Thu, 24 Mar 94 14:30:25 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjv1P-0005qMa; Thu, 24 Mar 94 11:24 PST
Date: Thu, 24 Mar 94 11:24 PST
Message-Id: <9403241814.AA29494@spiff.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: user/group -- my compromise proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   From: pat@it.com.au (Pat Mackinlay)
   Date: Fri, 25 Mar 1994 00:16:20 +0800 (WST)

   Sorry to bring this up *yet again*, but is there any chance at all that
   you could make the "default" uid "bin" or something other than root? As
   I've said before, the only major advantage is that it makes suid root
   binaries easier to spot, but I consider that important enough that I'd
   like to see it done.

   If it's too hard or whatever, I can understand and I'll just do it on
   the systems I look after, but I'd really appreciate it if it were the
   default for a "fresh" Debian 0.92 installation...

I'm perfectly happy with the current arrangement (obviously :) because
(1) setuid/setgid binaries are now mode [42]711 for security reasons,
which makes them stand out in `ls -l' output, and (2) setuid/setgid
files are now checked daily via cron and compared with the previous
day's results.

But... if others feel the same way I will consider the change.

   > (Would it be wise to start the user UIDs at 500 instead of 100?  I
   > don't forsee much of a conflict after 500, but I can at 100...)

As suggested earlier, I will use 1000.

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Thu Mar 24 17:01:11 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA22774; Thu, 24 Mar 94 17:01:04 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjxNG-0006Bda; Thu, 24 Mar 94 13:55 PST
Date: Thu, 24 Mar 94 13:55 PST
Message-Id: <199403241850.MAA29470@ahab.eecs.nwu.edu>
Errors-To: bruce@pixar.com
Reply-To: hpa@ahab.eecs.nwu.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: "H. Peter Anvin N9ITP" <hpa@ahab.eecs.nwu.edu>
To: debian-devel@pixar.com
Subject: Re: Private groups & umask 002 proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

> 
>  I'm still waiting to see one worthwhile argument against my proposal.
>  I don't expect to see one.
> 

I noticed you ignored my argument, which you previously dismissed with
a handwaving without giving an adequate solution.  My problem with
this proposal is that one loses one level of protection.

In the environment I work in, we have a policy which can be summarized
like this:

a) Other people in your working group can read, but not write, your
work files;

b) People not in your working group have no access.

The default umask is 026.

Under your scheme, one level of protections alias the other (uid alias
gid).  Hence there is *no way* such a policy can be implemented; it is
not possible to separate the people with read access from the ones
with no access.  This is a serious omission.

	/hpa

-- 
INTERNET: hpa@nwu.edu               FINGER/TALK: hpa@ahab.eecs.nwu.edu
IBM MAIL: I0050052 at IBMMAIL       HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512    STORMNET:    181:294/101
WWW hyplan available at <http://www.eecs.nwu.edu:8001/hpa/plan.html>

From debian-devel@pixar.com Thu Mar 24 19:11:41 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA24257; Thu, 24 Mar 94 19:11:35 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjzPa-0005pca; Thu, 24 Mar 94 16:06 PST
Date: Thu, 24 Mar 94 16:06 PST
Message-Id: <9403250806.A5210wk@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: stephen.white@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: stephen.white@adam.com.au
To: debian-devel@pixar.com
Subject: UUCP
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


 
The Debian UUCP package is useless. "uux" isn't included, which is an
astounding omission.
 
Is anyone handling UUCP, INN, or IDA sendmail for Debian? If not, I may be able
to provide working copies of these conforming to the Debian standard, if I have
time.
 
The IDA/MailX package on Sunsite is useless, since "dbm" was compiled on a
Sparcstation II, therefore (obviously) doesn't run under Linux.
 

From debian-devel@pixar.com Thu Mar 24 21:47:19 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA25391; Thu, 24 Mar 94 21:47:16 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pk1qE-0005qZa; Thu, 24 Mar 94 18:41 PST
Date: Thu, 24 Mar 94 18:41 PST
Message-Id: <9403250239.AA03613@spiff.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: UUCP
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Thu, 24 Mar 94 16:06 PST
   From: stephen.white@adam.com.au

   The Debian UUCP package is useless. "uux" isn't included, which is an
   astounding omission.

Yes.  Somewhere in the packaging process UUCP got thoroughly hosed.  I
apologize.  It's fixed now.

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Thu Mar 24 19:09:43 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA24242; Thu, 24 Mar 94 19:09:39 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjzNh-00064Ka; Thu, 24 Mar 94 16:04 PST
Date: Thu, 24 Mar 94 16:04 PST
Message-Id: <9403250806.A5199wk@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: stephen.white@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: stephen.white@adam.com.au
To: debian-devel@pixar.com
Subject: PRIVATE GROUPS 1/2
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO



 IJ> I see that you have `conveniently' elided the part of your
 IJ> message I was responding to:

It was "`conveniently' elided" to keep quotes to a minimum - or do you
prefer the B1FF style of quoting? I also "elide" (sic) irrelevant issues
to keep the basic discussion clear and understandable. I find that the
biggest handicap for any exchange of opinions is trying to debate every
point of contention.

But, since you insist, I shall endeavour to explain my apparently
incomprehensible utterings.

 IJ> False.  Quite a lot of activity happens in /tmp and /usr/tmp,
 IJ> on my system at least.

 SW> This is a non-argument. It is completely irrelevant to the issue.

The rebuttal was not denying that activity occurs in /tmp. It was denying
the relevance of such activity to the setgid vs BSD mount discussion.

 IJ> You claimed that all the action occurs in directories which would
 IJ> be setgid, and implied that only project and user home
 IJ> directories would be.
 IJ>
 IJ> Your claim was false, so the argument you based on it was unsound.

Incorrect. Your understanding of my argument is severely flawed.
Therefore, your refutations are unsound. Poetic, isn't it?

It appears that you base your claim on the following:

 ??> And [the] directories [which would be setgid] is [sic] where
 ??> all the action occurs.

Please note that the []'d portions are your additions, and those
additions change the meaning of my statement. This is a dishonest tactic,
Ian.

 SW> With the setgid scheme, virtually all activity will be conducted
 SW> under BSD semantics anyway.

This statement remains true. Or perhaps did you envision users frolicing
in the fairyland of /etc with SysV semantics? Perhaps a little day trip
over to /sbin with SysV semantics to recover from the drudge of labouring
under BSD semantics? Dearie me.

 SW> Why is there a ... requirement to have SysV semantics within /tmp
 SW> and /usr/tmp?

Would you please stop changing _my_ text in your quotes?

The "..." replaces the single word "continuing", and without that word it
looks as though I'm asking why SysV semantics were created for the /tmp
directory. I can only assume that this effect was deliberate, as there
was certainly no space saved by your modification.

Onto your main defence:

 IJ> Now, in general, if we adopt the private groups scheme the most
 IJ> important part of the ownership of a file will no longer be the
 IJ> user ownership but the group ownership,

 IJ> My first argument in this message against BSD semantics in /tmp
 IJ> is that this violates the general rule in my previous paragraph. 

This is a rather arbitrary rule, which ignores the fact that only the
owner of a file can chmod its permissions.

 IJ> My second argument in this message against BSD semantics is that
 IJ> it is generally less expected than System V semantics.

About as unexpected as setgid bits on directories, Ian.

 IJ> When using SysV semantics the setgid bit gives you a clear
 IJ> indication that something is happening to the group ownerships

It is only clear if you look, and know about setgid.

 IJ> When using BSD semantics this will be less clear, and the
 IJ> behaviour will therefore be further from that which might be
 IJ> expected.

You are advocating a mix of SysV and BSD and claiming it will have a more
expected behaviour?

To find out the group ownership of a created file under setgid:

  1) ls -ld ..
  2) Check the setgid bit.
  3) If it is set, then the group of the created file is the same as
     the group of the directory.
  4) Otherwise, the group of the created file is the same as the group of
     the creator.

Under BSD mount, it is simply:

  1) The group of the created file is always the same as the group of the
     directory.

Which looks more like conforming to "least surprise", Ian?



From debian-devel@pixar.com Thu Mar 24 19:09:02 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA24202; Thu, 24 Mar 94 19:08:58 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjzN1-0005oxa; Thu, 24 Mar 94 16:03 PST
Date: Thu, 24 Mar 94 16:03 PST
Message-Id: <9403250806.A5200wk@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: stephen.white@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: stephen.white@adam.com.au
To: debian-devel@pixar.com
Subject: PRIVATE GROUPS 2/2
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO



 SW> Can you explain how BSD managed all these years if SysV semantics
 SW> are such a requirement for /tmp?

 IJ> Neither of the two arguments I make above apply in a traditional
 IJ> BSD system with a umask of 022 or similar. The first argument
 IJ> doesn't apply because group ownership is generally irrelevant on
 IJ> such a system - access is controlled by user ownership.

This argument relies on your arbitrary rule being accepted as fact.

 IJ> The second argument doesn't apply for this reason as well,

And hence also relies on accepting your arbitrary rule as fact.

Despite this, it still remains irrelevant if the group ownership is
"fred" or "root" in the /tmp directory. If the group ownership is "fred",
then only fred and root can access the file. If the group ownership is
"root", then only fred and root can access the file. Notice the
difference? No, neither did I.

If fred wanted to share the file in /tmp, then, regardless of SysV or BSD
semantics in the /tmp directory, it is the "other" permission field that
is important. Therefore, it is irrelevant whether the /tmp directory is
operating under SysV or BSD semantics.

 IJ> and also because `ls' doesn't show the group ownership by default
 IJ> on BSD, thus hiding the unexpected behaviour (out of sight, out
 IJ> of mind).

Weak.

 SW> The fact remains that uid=gid is merely a disguised BSD filing
 SW> system.

 IJ> uid=gid has nothing to do with it.

I am aware of that. I was using the common name that has been applied to
the argument. Your personal prejudice against the name shouldn't prevent
you from understanding what I am saying.

I had not addressed the issue of making gid numbers equal uid numbers in
my entire message, so your misunderstanding is difficult to comprehend.

Would you understand if I rephrased it to: "The fact remains that the
entire scheme of setgid bits on directories is merely a disguised BSD
filing system"?

 SW> Incorrect. The one argument against mounting with BSD consituted
 SW> of "What happens if the admin sees the parameter in fstab and
 SW> removes it?".

 IJ> You have obviously not been reading the list.

Would you understand if I rephrased it to: "The one significant argument
against..."? This is unbearably misusing the word "significant", I admit.

 MH>         1. You can't get back the V7 semantics back for
 MH>                 individual directories.

You haven't explained why this is important.

 MH>         2. You're changing things for users without making
 MH>                 the change manifest.  (i.e. it seems as if
 MH>                 you're trying to sneak a change past the users)

Weak.

 MH>         3. It can be too easily turned off by an administrator
 MH>                 (Users start to rely on the bsds semantics then
 MH>                 one day some admin looks at fstab and thinks,
 MH>                 hey what does this do?  I think I'll take it
 MH>                 out (or not remember to put it in when modifying
 MH>                 it))

Pathetic.

 IJ> 4. It violates the principle of least surprise.  Files will be
 IJ> created (with a umask of 002, remember) with odd group ownership
 IJ> for no readily apparent reason.

I have already dealt with the fallacy of your argument of "least
surprise".

 IJ> The same could be said of setgid, but the g+s bit in the
 IJ> directory permissions is much more visible and is the kind of
 IJ> thing that people would believe might have this effect.

And I have dealt with this above.

 IJ> I believe that we're much more likely to want to turn off this
 IJ> feature for individual directories (/tmp and /usr/tmp come to
 IJ> mind immediately).

You haven't provided a concrete reason why, other than your refutations
based on an arbitrarily defined rule.

 IJ> In practice, I don't think that many sysadmins would bother
 IJ> turning it off even if we made it easy by mounting everything
 IJ> bsd-style.

And here, you go against your own argument.

 IJ> I think you would benefit from reading the alt.atheism FAQ file
 IJ> on how to construct a logical argument.  It can be found on
 IJ> rtfm.mit.edu in /pub/usenet/news.answers/atheism/logic.

By now it should be obvious that you need to read this more than I do.
Skimming through one of my text books, I find the flaws in your arguments
have the following names:

  1) Circulus in probando. Your reasoning begins with basic assumptions
     that cannot be proven except by proceeding to other conclusions
     which are based on those assumed in the beginning.

  2) The fallacy of sophistical refutations. To ridicule an argument, to
     exaggerate its claims so as to attack a "straw man" is another
     fallacy of irrelevancy. It may involve attributing to another a view
     that he does not hold.

The dismissal of your nerdy little insult over with, back to the
discussion. These are the essential facts:

Users will conduct virtually all their activities under BSD semantics.
User directories, source directories, and project directories. Note, that
/tmp is irrelevant.

Therefore the argument is, and only is, "Do we need SysV semantics at
all, knowing that BSD semantics are already in effect for virtually all
file operations?"

If it can be demonstrated that SysV semantics are required and the
benefits outweigh the extra complexity of a mixed BSD/SysV filing system,
then, by all means, setgid is the way to go, otherwise there is no
purpose in complicating things unnecessarily.

Implementing the user groups proposal with with BSD semantics is trivial.
Shove in a "grpid" in fstab, and make a small change in adduser. The
filing system remains homogeneous, permissions remain familiar, very
little explanation would be required in the Debian FAQ, and almost
everyone lives happily ever after. :)



From debian-devel@pixar.com Thu Mar 24 19:35:46 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA24377; Thu, 24 Mar 94 19:35:41 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pjzmt-0005qea; Thu, 24 Mar 94 16:30 PST
Date: Thu, 24 Mar 94 16:30 PST
Message-Id: <199403250029.KAA03938@extra.ucc.su.OZ.AU>
Errors-To: bruce@pixar.com
Reply-To: matth@ucc.su.oz.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Matthew Hannigan <matth@ucc.su.oz.au>
To: debian-devel@pixar.com
Subject: Re: user private groups and a src group 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Remy.Card@masi.ibp.fr writes in part
>         BTW, it seems to me that this thread gives me the opportunity to
> suggest the changes in the default behavior for directory semantics.  As I
> said before in this list, I am willing to change the ext2fs default behavior
> to use BSD semantics and implement it in other filesystems.  I will contact
> other filesystem developers to check if they have objections and then I will
> send a proposal on the KERNEL channel.

Well I can agree to this at least!

However, in general, I'm suffering a bit of mail fatigue
on this issue.  I'm still convinced that the proposal
is an excellent one, and to introduce it would do no harm
and a lot of good.

But also it is no good half-introducing it.  If we don't make it
the default (no questions at install time), I say don't bother
at all; at least not the next release of debian.

--
	-Matt Hannigan

From debian-devel@pixar.com Thu Mar 24 23:00:01 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA25543; Thu, 24 Mar 94 22:59:58 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pk2ya-0005qoa; Thu, 24 Mar 94 19:54 PST
Date: Thu, 24 Mar 94 19:54 PST
Message-Id: <9403250358.AA25528@thorplus.lib.purdue.edu>
Errors-To: bruce@pixar.com
Reply-To: mdickey@thorplus.lib.purdue.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdickey@thorplus.lib.purdue.edu (Mike D.)
To: debian-devel@pixar.com
Subject: Re: UUCP
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian wrote:
>   From: stephen.white@adam.com.au
>
>   The Debian UUCP package is useless. "uux" isn't included, which is an
>   astounding omission.
>
>Yes.  Somewhere in the packaging process UUCP got thoroughly hosed.  I
>apologize.  It's fixed now.

However, Debian needs a UUCP packager and maintainer.  Please write me,
Stephen, if you would be able to handle this.

Anyone else out there, in case Mr. White cannot do it, please step up.

Mike D.
-------
mdickey@thorplus.lib.purdue.edu        Use Debian Linux

From debian-devel@pixar.com Fri Mar 25 00:31:28 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA25865; Fri, 25 Mar 94 00:31:23 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pk4P3-0005r5a; Thu, 24 Mar 94 21:25 PST
Date: Thu, 24 Mar 94 21:25 PST
Message-Id: <9403250523.AA21197@then.midnight.com>
Errors-To: bruce@pixar.com
Reply-To: birkholz@midnight.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: birkholz@midnight.com (Matt Birkholz)
To: debian-devel@pixar.com
Subject: Private groups & umask 002 proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Thu, 24 Mar 94 13:55 PST
   From: "H. Peter Anvin N9ITP" <hpa@ahab.eecs.nwu.edu>

   [...]

Oy.  Why do I have to explain this?

   In the environment I work in, we have a policy which can be summarized
   like this:

   a) Other people in your working group can read, but not write, your
   work files;

You say "working group"; I say "project".  Is there a difference?

Your default is read-only; mine is read-write.  Now, _that_ is a simple
change.  Getting the "working group" directories created as such is the
hard part.

With common cause like that, why aren't you _with_ us, brother?

   [...]
   Hence there is *no way* such a policy can be implemented; it is
   not possible to separate the people with read access from the ones
   with no access.

There would be a problem if you needed to specify two groups of people with
differing access requirements.  You've specified one.  A umask of 026 is
what you want.  Stick it in /etc/profile and /etc/csh.login.

   This is a serious omission.

If it is, you need to explain some more.

Matthew Birkholz
birkholz@midnight.com

From debian-devel@pixar.com Fri Mar 25 07:36:11 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA26525; Fri, 25 Mar 94 07:36:08 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkB25-0009R4a; Fri, 25 Mar 94 04:30 PST
Date: Fri, 25 Mar 94 04:30 PST
Message-Id: <199403251229.AA25254@masi.ibp.fr>
Errors-To: bruce@pixar.com
Reply-To: Remy.Card@masi.ibp.fr
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Remy.Card@masi.ibp.fr (Remy CARD)
To: debian-devel@pixar.com
Subject: Re: UUCP
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

> 
> 
> Is anyone handling UUCP, INN, or IDA sendmail for Debian? If not, I may be able
> to provide working copies of these conforming to the Debian standard, if I have
> time.
>  
> The IDA/MailX package on Sunsite is useless, since "dbm" was compiled on a
> Sparcstation II, therefore (obviously) doesn't run under Linux.

	I have compiled sendmail 8.6.8 (the latest and greatest) under Linux.
My version can use dbm maps but can also use the new db library from Berkeley.

	The IDA features have all been included in sendmail 8 so it may be
worth considering including sendmail 8 in Debian.  I can package it for Debian
if people agree (and if someone sends me a copy of the guidelines for making
a package -- sorry, I have lost my copy).

		Remy

From debian-devel@pixar.com Fri Mar 25 09:01:21 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA27153; Fri, 25 Mar 94 09:01:18 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkCMV-0009Pxa; Fri, 25 Mar 94 05:55 PST
Date: Fri, 25 Mar 94 05:55 PST
Message-Id: <9403251353.AA09566@spiff.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: Packaging for Debian
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Fri, 25 Mar 94 04:30 PST
   From: Remy.Card@masi.ibp.fr (Remy CARD)

   > Is anyone handling UUCP, INN, or IDA sendmail for Debian? If not, I
   > may be able to provide working copies of these conforming to the
   > Debian standard, if I have time.

   > The IDA/MailX package on Sunsite is useless, since "dbm" was
   > compiled on a Sparcstation II, therefore (obviously) doesn't run
   > under Linux.

   I have compiled sendmail 8.6.8 (the latest and greatest) under
   Linux.  My version can use dbm maps but can also use the new db
   library from Berkeley.

   The IDA features have all been included in sendmail 8 so it may be
   worth considering including sendmail 8 in Debian.  I can package it
   for Debian if people agree (and if someone sends me a copy of the
   guidelines for making a package -- sorry, I have lost my copy).

The `final' guidelines are being worked out, and I should have a copy
of them out by the weekend.  Please don't use the old ones to actually
package anything, but do feel free to look at them to get the general
idea.  A few people submitted source packages based on the guidelines
and I noticed that I forgot to include a few (minor) points.

BTW, we're going to have a new development FTP site here in a few
days; on this site everything needed by the Debian project in its work
may be found, including volunteer lists, packaging guidelines and
working source packages.  Due to lack of disk space on sunsite (at
present, at least) this is also where the source distribution is going
to be located.  I'll announce the name of the site once we upgrade the
brain-dead version of ftpd that came with the system and make a few
other changes.

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Fri Mar 25 06:35:53 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA26378; Fri, 25 Mar 94 06:35:49 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkA5i-0009I0a; Fri, 25 Mar 94 03:30 PST
Date: Fri, 25 Mar 94 03:30 PST
Message-Id: <m0pk1B0-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: User private groups - reply to Remy Card (devel)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

(This message is essentially a bunch of responses to issues and points
left over after Ian Murdock's proposal.)

Remy Card writes:
> [much wibbling about RCS deleted]

I'll not respond to this in detail.  David Engel has stated clearly
the mistake you're making here.

>         So, your proposal does not work in a networked environment where a
> PC running Linux needs to interact with NFS servers which use the de-facto
> standard way of attributing uid and gid?  If so, this is a big restriction.

No, my proposal does work (as does Ian's compromise) as well as any
system.  Under these circumstances you have to put up with what you're
given anyway; my proposal doesn't make it any harder to conform to
your site's practices.  In fact, if your site does user private groups
it will actually gain you something ...

>         You seem to consider that the group inheritance is only useful for
> sharing write access to files.  I do not agree.  At our university, we use
> this to allow read access to some files for some users belonging to the
> same group (with umask = 027).  Even if a shared write access is not needed,
> groups can still be use to share read access.

This can easily be solved by using nested directories appropriately:

drwxr-s---   7 imurdock readers       512 Mar 25 00:08 /project/foo
drwxrwsr-x  10 imurdock writers      2048 Mar 25 00:08 /project/foo/work

I can see that some people might consider this less elegant than
having a umask of 027; however it does allow you to control access to
files based on their location rather than by changing your umask all
the time.

I have worked on systems where file protection is based on the name of
the file and it really is very convenient indeed - it's also bloody
obvious and hard to make mistakes about.

(H. Peter Anvin tells me that he also made a similar point earlier on
and that I "dismissed [it] with a handwaving without giving an
adequate solution".  If so I apologise.  However I don't remember
responding to any of his messages, so perhaps I just missed it.)

> Can you please explain this `uid/gid unification in the kernel' ?
> [stuff deleted]

Well, it goes like this: you arrange for the kernel to no longer
distinguish between uids and gids.  Your process merely has a list of
zero or more ids attached, some of which will belong to you personally
and some of which will belong to groups of people.  You still need to
have a `uid' and `gid' to say what ownership to give created files,
but they're just used there (of course they'd be in the list as well).

Then it becomes possible (for example) to make a file owned by a
group, so that any member of the group may chmod/chown it.

As I understand it the Hurd will be doing something like this (though
probably not necessarily with particularly unix-like permission
information attached to files - I don't know about this).  I've gained
this impression from reading various technical information about the
Hurd.

(Note to the potentially confused reader: the above 3 paragraphs are
*not* part of the `user private groups' proposal that I've been
arguing in favour of on this list!)

>         What's that?  Does Debian contain a group that is allowed to su root
> without any password?  If so, this may open a security risk since this may be
> easier to guess one of N passwords than the single root password to get
> superuser priviledges.

Yes, thank you, I'm well aware of this kind of issue.  Debian doesn't
contain such a group, however there's no reason some people shouldn't
be allowed to have one if they want it.

The way I've implemented this on my system is to make some
security-critical file (/etc/inittab, I believe) writeable by the
group in question.  Then I have a suid-root program that will
automatically let you in if you have write access to this file.

This would be a nice feature to have in the `su' in Debian (perhaps
using a writeability check on `/'), which would allow people to make
this kind of thing a matter for local policy.

>         Hmm, why do you restrict you to Linux distributions?  Go ahead, Mr
> Jackson, extend your proposal to other Unix distributions.  Why don't you
> propose that your private groups idea be implemented in the BSD distributions
> for example?

Because I'm not a BSD developer, beta tester, documentation
maintainer, etc.  Rest assured that if I were I would be pressing for
my proposal there just as hard as I am here.

> [ re more radical kernel changes ]
> 
> > This is not a matter for the Debian list, more for the KERNEL channel
> > and/or col.development.  I'd be very interesting to hear your ideas -
> > in the right place.  Debian will have to work with the kernel as it is
> > now.
> 
>         I strongly disagree.  I think that people can discuss some needed
> extensions to the kernel before submitting a proposal to the KERNEL channel
> and/or the filesystem developers.  After all, if an extension is needed for
> Debian, it can be discussed on a this mailing list and submitted to the
> kernel developers if/when there is a consensus on it.

It's not `needed'.  Whether it would be nice is another thing.  If it
would be nice it would be nice in the standard kernel, at least as an
option - this is therefore *not* a Debian-specific issue.

Given the astonishing negative response I've had on this list to a
commonly used and effective scheme I don't think more radical and
ideas whose usefulness might even be slightly doubtful would go down
at all well.

> > If people seriously doubt that sane use of the group write permission
> > is useful I can easily come up with several examples that I personally
> > have been involved with.
> 
>         Please describe them.  You always say `I can easily give real examples'
> but you never explain them.  Can you please describe them to serve as a basis
> for future discussion.

The Cambridge University Computer Society and the C.U. Science Fiction
Society both maintain filespaces on various multiuser systems.  These
filespaces are kept writeable by the committee; portions are readable
only by the membership, other portions are globally readable.  The
filespaces generally contain things like shared mail folders used for
accessing a society mailbox (locking was done by the mailer - only one
person could use the mail folders at a time), publicity material,
libraries of commands useful to committee members and or ordinary
users (these libraries are maintained by one person, but the committee
all need write access to fix urgent problems, etc.)

I'm currently working on a project to replace a bulletin board system
running on the IBM Phoenix/MVS mainframe here.  On the IBM the Editors
have a shared filespace which they all have access to.  The software
is changed infrequently and doesn't need revision control, and the
message spool area is protected by operating system locking
techniques.  The replacement is a TCP/IP-based server, however I'm
currently having some difficulty because (due to political problems)
I'm not allowed to use the shared filespace allocated on the Central
Unix Service for the `replacement bulletin board'.  This makes it much
harder to share files with my co-developers.  If and when the politics
are sorted out all the stuff will go in the shared filespace.  Again,
revision control is not necessary, because all the major software
development is being done by only one person per large component;
however shared access to administrative data, message spools, etc, is
vital.

My 2rd-year `software engineering' project, where I was working with
one other person in a shared filespace.  We weren't editing "each
others'" files, though we had a shared source/build tree.  If we
needed `conflict resolution' we spoke to each other - we were
generally working on adjacent workstations.  We were given a shared
filespace but had to use newgrp and umask to access it correctly - the
results were difficult to manage.

>         Hmmm, I don't understand.  I thought that permissions had to be changed
> on user and project directories.  Why should we change the permissions on
> the system and application directories?

Here's another example:

Systems in general are often managed by groups of people rather than
single individuals.  It makes life a lot easier if all the relevant
files are accessible to the relevant people - you can just type `make
install' and have it work without worrying too much about permissions.
All the members of the `mail' group can go and edit the config files,
clear stuck queues, etc, without having to su and type passwords all
the time.

> ... .  Allowing a group of users to modify these directories
> may create security risks.

That depends on who the groups of users are and what they could do
anyway, clearly.  Your point ?

>         The only argument against mounting filesystem with BSD semantics seems
> to be `what happens if the administrator removes the bsd option from
> /etc/fstab.  Using setgid directories opens the same risks: what happens if
> the administrator or the directory owner removes the setgid bit?

Please see Matthew Hannigan's message and my followup, and my more
recent message in response to Stephen White.  I'm sad to see that I
have to repeat myself and refer people back to things I've already
said so much.

> BTW, it seems to me that this thread gives me the opportunity to
> suggest the changes in the default behavior for directory semantics.  As I
> said before in this list, I am willing to change the ext2fs default behavior
> to use BSD semantics and implement it in other filesystems.  I will contact
> other filesystem developers to check if they have objections and then I will
> send a proposal on the KERNEL channel.

Please do not do this.

BSD behaviour for a whole filesystem is both a kludge and unexpected,
and making it the default is even worse.

Please read the messages from Matthew Hannigan and myself, which
listed around 4 reasons not to do this.


From debian-devel@pixar.com Fri Mar 25 06:51:58 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA26468; Fri, 25 Mar 94 06:51:55 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkALI-0009Q4a; Fri, 25 Mar 94 03:46 PST
Date: Fri, 25 Mar 94 03:46 PST
Message-Id: <m0pk1AB-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: user/group -- my compromise proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

SUMMARY:

I've read Ian Murdock's message, and it seems basically fair enough.

It appears to solve the problem of upgrading, at the cost of having
systems potentially end up with a somewhat inconsistent arrangement.


CAVEAT re the DEFAULT:

However, I still feel strongly that the envisaged option should be the
default for adduser.

This is basically because it will make life so much easier for all the
new system administrators we are creating.  It may make documentation
easier as well (how do I do XYZ ?  Type ..., err, sorry, I mean su to
src and ...).

I believe any political noise will die away when people actually get
to use the system and see that it doesn't cause major problems.  In
any case, we must not allow ourselves to be dissuaded from doing
something merely because some very vocal people oppose (or indeed
support) it - issues of substance should carry the day (whichever way
it goes).

Having an arrangement where you have to remember to specify the option
each time you add a user could result in systems where some of the
shared files aren't updateable by some of the appropriate users
because the person to create them had their account created without
the magic option.

Turning it on by default solves this problem.

It also means that when someone comes along and writes a bunch of
programs which allow users to create, modify and delete groups it will
actually be useful to the majority of installations.

Turning it on by mistake for a particular user has less severe
consequences; any problems (which would be aesthetic, really) could be
solved at the sysadmin's leisure rather than having irate users coming
beating on their door saying `joe has left all these files here and I
can't write to them ...' - eg, joe installed GNU Gnomovision in
/usr/local and it created the /usr/local/lib directory but joe's umask
is 022 and etc. etc. etc.


ADDITIONAL COMMENTS ON ADDUSER:

A way to turn private group creation off and on globally would be very
useful, of course - I don't imagine that many systems would want a
half hearted scheme.

That would probably go a long way to keeping both sides happy - even
the side that doesn't get their way on the default.

Incidentally, while we're on the subject of adduser, a place to
configure the default location of home directories would be nice (and
a bit more interaction on the part of adduser before it goes and does
it's stuff).


ADDITIONAL COMMENTS ON UMASK

I'm not convinced about leaving the system umask in /etc/profile (&c)
set to 022 and not setting it in the setup files of users who don't
get their own group (this is of course a slightly different issue to
whether creating an additional group should be the default in
adduser).

This will present us with a problem if you ever want to change the
umask in /etc/profile.  I'd suggest that the umask for each user
should be explictly set in their default startup scripts (both the sh
and csh versions).  Then you can have what you like in the system file
and it won't matter much, and system upgrades are less likely to have
unexpected consequences.


MISCELLANEOUS COMMENTS:

Starting user UIDs at 1000 is indeed a good idea.  Also, Paul Vojta's
comments on the desirable behaviour of adduser under certain
conditions are well considered (labelled C' in his message.)

David Engel is of course correct to say that /boot should be group
`disk' or `root'.  Incidentally, what is the permission of / ?

Files in /bin etc. shouldn't really be owned by bin by default, if for
no other reason that it makes NFS easier to use to penetrate the
system.  NFS is quite bad enough already without making the holes
*completely* obvious.  (Yes, I know this can be fixed by `proper use',
it just strikes me as needless risk.)

Paul Vojta's message ("I'd like to dissect Ian's proposal") was very
interesting.  It seems to agree in some sense with what Ian Murdock is
now proposing to do.

I have responded to Remy Card's long messages, which appear to have
been written before Ian Murdock's message, in a separate posting on
each list.


Ian.

SILLY MESSAGE:

Boo!

From debian-devel@pixar.com Fri Mar 25 15:27:47 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01253; Fri, 25 Mar 94 15:27:42 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkIOR-000AOLa; Fri, 25 Mar 94 12:22 PST
Date: Fri, 25 Mar 94 12:22 PST
Message-Id: <9403252020.AA03100@odin.ucsd.edu>
Errors-To: bruce@pixar.com
Reply-To: imcclogh@cs.ucsd.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Ian McCloghrie <imcclogh@cs.ucsd.edu>
To: debian-devel@pixar.com
Subject: Re: UUCP 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

On Mar 25, 1994 Remy CARD wrote:
> > Is anyone handling UUCP, INN, or IDA sendmail for Debian? If not, I may be 
able
> > to provide working copies of these conforming to the Debian standard, if I 
have
> > time.
> 
> 	I have compiled sendmail 8.6.8 (the latest and greatest) under Linux.
> My version can use dbm maps but can also use the new db library from Berkeley

Has Ian Kluft dropped off the list?  Last I heard, he was handling the
entire mail subsystem, smail, sendmail, uucp, etc.

--
 /~> Ian McCloghrie      |       FLUG:  FurryMUCK Linux User's Group
< <  /~\ |~\ |~> |  | <~ | email: ian@ucsd.edu               Net/2, USL 0!
 \_> \_/ |_/ |~\ |__| _> | Card Carrying Member, UCSD Secret Islandia Club
GCS (!)d-(--) p c++ l++(+++) u+ e-(soon) m+ s+/+ n+(-) h- f+ !g w+ t+ r y*

From debian-devel@pixar.com Fri Mar 25 16:14:14 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01764; Fri, 25 Mar 94 16:14:12 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkJ7R-000AOta; Fri, 25 Mar 94 13:08 PST
Date: Fri, 25 Mar 94 13:08 PST
Message-Id: <9403252107.AA23926@bb29c.mdd.comm.mot.com>
Errors-To: bruce@pixar.com
Reply-To: mitchell@mdd.comm.mot.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
To: debian-devel@pixar.com
Subject: Re: user/group -- compromise proposal -- __DOCUMENTATION__
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

I'm going to beat a large bass drum about __DOCUMENTATION__ a bit here.

---------------------------------------------------------------------------

iwj10@cus.cam.ac.uk (Ian Jackson) said:

> SUMMARY:
> [...]
> Turning it on by default solves this problem.

And it needs to be turned on in such a way that it's straightforward
to find out what default was chosen and what needs to be done to change
it later.  This has been mostly bypassed in past discussion with remarks
like "that's easily handled in a FAQ".  I don't think that's sufficient.

Even if an FAQ is sufficient, this doesn't become a non-issue until the
FAQ with this item sufficiently covered is part of the distribution.

I'd say that if debian is going to present special admin issues which
are not covered in the Linux SAG, then the debian project needs to produce
an addendum or appendix to the Linux SAG which covers those issues in the
same depth and with the same quality of presentation as the Linux SAG.

>[...]
> ADDITIONAL COMMENTS ON ADDUSER:
> 
> A way to turn private group creation off and on globally would be very
> useful, of course - I don't imagine that many systems would want a
> half hearted scheme.
> 
> That would probably go a long way to keeping both sides happy - even
> the side that doesn't get their way on the default.
> 
> Incidentally, while we're on the subject of adduser, a place to
> configure the default location of home directories would be nice (and
> a bit more interaction on the part of adduser before it goes and does
> it's stuff).

All of this stuff falls into the category of what I was talking about above.
If we're going to twiddle this and twiddle that and create special admin
issues here and and special user issues there there, we need to be thinking
about documenting all this.

No, strike that.  We need to be documenting it as we are implementing it,
not thinking about documenting it; and we should not be releasing it with 
the special issues in it unless it is accompanied by documentation of the 
special issues.

> ADDITIONAL COMMENTS ON UMASK

Any nontraditional umask usage needs to be prominently documented.  This
goes beyond the SAG, it's something that'll need to be documented clearly
at the user level.  This probably means a debian addendum to the Linux
Installation and Getting Started document.  Hmmmmm..... that document includes
sections on
  1) Introduction to Linux
  2) Obtaining and Installing Linux
  3) Linux Tutorial
  4) System Administration
  5) Advanced Features 
I haven't looked at a copy of this document lately but, from the section
titles, it seems like there might be debian-specific issues in section 2
in any case, and issues specific to this user/group (or whatever this week's
politically correct nomenclature for it is) proposal in sections 3 and/or 4.

> MISCELLANEOUS COMMENTS:
> 
> Starting user UIDs at 1000 is indeed a good idea.  Also, Paul Vojta's
> comments on the desirable behaviour of adduser under certain
> conditions are well considered (labelled C' in his message.)

And if we're going to start UIDs at 1000 (or whatever) we need to explain
why we did that, explain it well, and and explain it prominently.  This
probably means explaing why in a debian SAG addendum, _and_ in a note on the
adduser manpage, _and_ (if adduser is a script -- I don't have a debian system
handy to look at) in comments inside the adduser script.

----------------------------------------------------------------------------

I know, it's easy to pass this off with a "that's just a documentation issue",
and presume that it'll be dealt with later.  I'm concerned that anything which
is regarded as _just_ a documentation issue, and OK to put off until later
simple because it's _just_ a documentation issue, might never get dealt with
properly (or at all).

I'm getting the feeling that it's likely debian will implement something
in this area in 0.92.  If so, debian 0.92 should include at least half-assed
documentation of what's been done, of the effects it'll have on sysadmin, and
of the effects it'll have on Joe User (who won't care) and Jane User (who
will find it useful once she understands it and understands how to take
advantage of it).

Before debian goes into general non-beta release, the documentation needs
to be better than half-assed.  That means getting a documentation project
going -- probably in close cooperation with the individuals producing
general Linux documentation.

-- (Returns large bass drum to storage) --



From debian-devel@pixar.com Fri Mar 25 21:16:48 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA03241; Fri, 25 Mar 94 21:16:45 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkNqE-0009nwa; Fri, 25 Mar 94 18:11 PST
Date: Fri, 25 Mar 94 18:11 PST
Message-Id: <9403260215.AA03231@thorplus.lib.purdue.edu>
Errors-To: bruce@pixar.com
Reply-To: mdickey@thorplus.lib.purdue.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdickey@thorplus.lib.purdue.edu (Mike D.)
To: debian-devel@pixar.com
Subject: contributions
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

This is a response to the entire lot of questions concerning who's doing
what packages lately.

Once again, I am keeping track of the package maintainers.  If you want
to contribute a package, before you even think about going through all
the trouble of finding out how to package it to dpkg format, and go
through all the trouble of bugging Ian and whoever else about when the
specs for the dpkg format will be out, _ask me first_.  I know who is
doing the packages.  At least I know who is doing them, by virtue of the
packager keeping me in the know.

I will post the entire WHOS_DOING_WHAT file at the end of this message
for everyone's review.  Look over it if you are doing a package and have
not contacted me.  Look over it if you're thinking of doing a package.
Look over it if you know of someone who is thinking of doing a package.
And so on.

It will also be available at the new Debian ftp site, when that becomes
publicly available (it is not available yet, in case that wasn't
obvious).  It has been available at sunsite, in the Debian directory
(forgive me for barfing on the exact location) - but that has not been
updated in about 2 weeks.

And thanks in advance for keeping in touch with me.

Mike D.
-------
mdickey@thorplus.lib.purdue.edu        Use Debian Linux

-- cut -- -- cut -- -- cut -- -- cut -- -- cut -- -- cut -- -- cut --
			   WHO'S-DOING-WHAT
		       Last updated: 94 Mar 25
			  By: Mike L. Dickey
		  <mdickey@thorplus.lib.purdue.edu>

** HAVE's **

Name		  Email Address				Package(s)
----------------  ------------------------------------	---------------
[These packages will be included in the distribution proper.]

Mathew Porter	  porterm@camelot.eng.ohio-state.edu	ncurses
Jonathan Rozes	  jrozes@cs.tufts.edu			kerberos,
							security
Mike Sangrey	  mike@sojurn.lns.pa.us			TeX
Dan Quinlan	  quinlan@spectrum.cs.bucknell.edu	Emacs, sman,
							groff,
							rescue disk
Ian Kluft	  ikluft@thunder.sbay.org		smail
Ian Jackson	  iwj10@cus.cam.ac.uk			INN, trn
Matt Welsh	  mdw@sunsite.unc.edu			docs
James Robinson	  jimr@simons-rock.edu			ispell
Anthony Hall	  aehall@seattleu.edu			fixperms
Ted Hajek	  tedhajek@boombox.micro.umn.edu	ghostscript
Helmut Geyer	  geyer@kalliope.iwr.uni-heidelberg.de	X11
Peter Tobias	  tobias@server.et-inf.fho-emden.de	base networking
Bill Mitchell	  mitchell@mdd.comm.mot.com		lilo, elvis,
							less, npasswd,
							mtools, patch,
							shar, uuencode
Sal (?)		  svalente@athena.mit.edu		mailx
Stephen White	  stephen.white@adam.com.au		UUCP
Matthew Bailey	  mbailey@cps201.cps.cmich.edu		PPP

----------------  ------------------------------------	---------------
[These packages will be included as options, or add-ons.]

Charlie Brady	  charlieb@tplrd.tpl.oz.au		pine, pico
James Robinson	  jimr@simons-rock.edu			OpenWindows
Brandon Allbery	  bsa@kf8nh.wariat.org			MH
Jonathan Rozes	  jrozes@cs.tufts.edu			sendmail
Mark Denovich	  mark@clewis.ws.cc.cmu.edu		AndrewToolKit
David Inman	  INMANDMK@vms1.bham.ac.uk		tcl/tk
Clark McGrew	  mcgrew@skid.ps.uci.edu		FlexFax
Erik Talvola	  talvola@fennel.berkeley.edu		X11 games
Michael Deisher	  deisher@enws125.eas.asu.edu		dosemu
Ted Hajek	  tedhajek@boombox.micro.umn.edu	gopher, ncftp
James Robinson	  jimr@simons-rock.edu			graphics/math 
							stuff, term
Mathew Porter	  porterm@camelot.eng.ohio-state.edu	ftape

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

From debian-devel@pixar.com Fri Mar 25 23:46:13 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04125; Fri, 25 Mar 94 23:46:10 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkQAp-000Aa4a; Fri, 25 Mar 94 20:40 PST
Date: Fri, 25 Mar 94 20:40 PST
Message-Id: <Pine.3.89.9403252331.A4571-0100000@vani>
Errors-To: bruce@pixar.com
Reply-To: mbailey@cps201.cps.cmich.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Matt Bailey <mbailey@cps201.cps.cmich.edu>
To: debian-devel@pixar.com
Subject: Mosaic: Call to order :)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Anyone here working on a mosaic distribution I think that it should be a 
add on .....

Sorry I do not have time for this that is why I am asking



--
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||                                ||  root@stimpy.cps.cmich.edu      ||
|| Matthew S. Bailey              ||  mbailey@cps201.cps.cmich.edu   ||
|| 109 Merrill Hall               ||  32bdzwc@cmuvm.csv.cmich.edu    ||
|| Central Michigan University    |||||||||||||||||||||||||||||||||||||
|| Mt. Pleasant  MI  48858        ||  Get rid of MS-DOG and switch   ||
|| (517) 774-4141                 ||  To a real Operating System     ||
||                                ||         L I N U X!!             ||
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||








From debian-devel@pixar.com Sat Mar 26 10:53:06 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04878; Sat, 26 Mar 94 10:53:03 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkaaB-0006ANa; Sat, 26 Mar 94 07:47 PST
Date: Sat, 26 Mar 94 07:47 PST
Message-Id: <m0pkaYb-0002DHC@simons-rock.edu>
Errors-To: bruce@pixar.com
Reply-To: jimr@simons-rock.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: "James A. Robinson" <jimr@simons-rock.edu>
To: debian-devel@pixar.com
Subject: Re: user private groups and a src group 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

> 	I am sorry that waste more bandwith by replying to this thread but
> Mr Jackson does not seem to accept that other people may have other opinion
> so I have to reply to explain again.

It seems that two debates exist,

	1.  Software development under the current layout WITHOUT
	    version control software is extremely difficult if
	    you have multiple developers.

	2. The current layout for new users and lazy users if
 	   difficult to manage, and the concept of groups is
           "useless" unless you actually use them.

It would seem that with combining Ian Murdock's proposal for making a
group for administration (widely accepted), version control software
on the /usr/src and /usr/local/src or whatever directories for
development, you can solve the problems in #1.  However, it seems that
we could use Ian Jackson's scheme to add a group for each user, and
use that layout ONLY on home directories.  Now this would be easily
added or removed depending on the taste of the administrator.

So we solve the problem of needing file locking on software under
development, allow non root users in a special group to install new
software and manuals, as well as give administrators the option to
make life easier for the newbie user who does not know about modes. It
ALSO gives the benefit of allowing the user to let selective other
people into their directories.

This of course means a lot more work for the debian team than just
"going one way."  If we combine the best of both ideas it seems that
while the Debian developers would have a little more work, it would
give a great deal of freedom to the admin to choose his/her stance on
what is obviously a volatile concept.

Jim Robinson

--
Jim Robinson           jimr@simons-rock.edu
Simon's Rock College   jimr@cs.wisc.edu

From debian-devel@pixar.com Sat Mar 26 11:11:05 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04958; Sat, 26 Mar 94 11:11:01 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkara-0005r2a; Sat, 26 Mar 94 08:05 PST
Date: Sat, 26 Mar 94 08:05 PST
Message-Id: <m0pkKU2-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: BSD mount vs. Setgid - reply to Stephen White
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

(Readers not interested in flamewars will find this message most tedious.
 Unfortunately it seems I have to go into considerable detail to
 make myself understood by Stephen White.)

>  IJ> I see that you have `conveniently' elided the part of your
>  IJ> message I was responding to:
> 
> It was "`conveniently' elided" to keep quotes to a minimum - or do you
> prefer the B1FF style of quoting? I also "elide" (sic) irrelevant issues
> to keep the basic discussion clear and understandable. I find that the
> biggest handicap for any exchange of opinions is trying to debate every
> point of contention.

I prefer to have enough quoted material so that the arguments that are
being made can be followed.  If you delete the context statements
become meaningless.

If you don't want to debate a point of contention then don't debate
it; don't quote the last few lines and add some meaningless
`refutation'.

>From this point on I shall mark quoted text that I have reinserted to
provide relevant context with `}' symbols.  I have also reedited
things to a more usual Usenet-style quoting, as this allows the proper
chronology and relationship of messages to be seen.

BTW, according to Chambers English Dictionary:
  elide ... v.t. to rebut (arch.): to cut off, as a syllable: to
  suppress, abridge.  n. elision (...) ... . [L. elidere, elisum -e,
  from laedere, to strike.]

It seems that I overestimated your reading level and initiative
(presumably you have access to a dictionary).

Stephen White writes:
} [Ian Jackson writes:]
}} Stephen White writes:
}}} [Ian Jackson writes:]
}}}}} And [the] directories [which would be setgid] is [sic] where all the
}}}}} action occurs. With the setgid scheme, virtually all activity will
}}}}} be conducted under BSD semantics anyway.
}}}} 
>>>> False.  Quite a lot of activity happens in /tmp and /usr/tmp,
>>>> on my system at least.
>>> 
>>> This is a non-argument. It is completely irrelevant to the issue.
>> 
}} You claimed that all the action occurs in directories which would be
}} setgid, and implied that only project and user home directories would
}} be.
}}
}} Your claim was false, so the argument you based on it was unsound.
} 
> The rebuttal was not denying that activity occurs in /tmp. It was denying
> the relevance of such activity to the setgid vs BSD mount discussion.

You appear to be confused as to who was producing an argument and who
was rebutting it.  As can be seen above, you argued that:
  "[virtually] all activity occurs in setgid dirs" =>
   "[virtually] all activity occurs in BSD semantics"

However, your premise was false and your argument therefore unsound.
When I pointed this out your replies became nonsensical.

It is possible that you are trying to express the argument:
  "all the relevant activity occurs in setgid dirs" =>
   "all the relevant activity occurs in BSD semantics"
Unfortunately you must then justify your assertion that the activity
in /tmp is not relevant; you have not yet done so.  (To say that it is
not relevant because it doesn't happen in a setgid directory would be
circular, of course.)

> It appears that you base your claim on the following:
> 
>>>>> And [the] directories [which would be setgid] is [sic] where
>>>>> all the action occurs.
> 
> Please note that the []'d portions are your additions, and those
> additions change the meaning of my statement. This is a dishonest tactic,
> Ian.

Firstly, it has taken you a long time to spot this.  If my quote had
been a misquote it would have saved a lot of aggravation if you'd
bothered to read my message several exchanges ago.  However, it's not
even true that I have misleadingly quoted you.  See below.

Furthermore you have no basis for your claim that it was a `dishonest
tactic' on my part - to substantiate this you must show that I
deliberately intended to mislead.  I demand that you substantiate your
claim of dishonesty on my part or withdraw it and apologise forthwith.

Here is what Stephen White wrote, that he claims I misleadingly
edited (I have reformatted it to fit in 80 columns):
}}}}} So, what exactly are the setgid's being used for? Answer; to create BSD
}}}}} semantics for selected directories, those being the user directories and
}}}}} project directories.
}}}}} 
}}}}} And those directories is where all the action occurs. With the
}}}}} setgid scheme, virtually all activity will be conducted under
}}}}} BSD semantics anyway.

My edits were to delete the first paragraph, as it wasn't part of the
context I wished to quote, and then to replace the word `those'
applied to `directories' with `the ... which would be setgid'.

`those directories' refers to the `selected directories' from the
previous paragraph, which are precisely the directories that in my
scheme would be setgid, hence `the ... which would be setgid'.

Perhaps you would like to explain in what way I changed your meaning.

>> Why is there a ... requirement to have SysV semantics within /tmp
>> and /usr/tmp?
> 
> Would you please stop changing _my_ text in your quotes?
> 
> The "..." replaces the single word "continuing", and without that word it
> looks as though I'm asking why SysV semantics were created for the /tmp
> directory. I can only assume that this effect was deliberate, as there
> was certainly no space saved by your modification.

I deleted the word `continuing' because I didn't see how it affected
the meaning.  I try to trim text down to the minimum which will have
the same meaning, so that those trying to follow the argument have to
lead less `extraneous' material.  This is perfectly acceptable
practice.  If you don't believe me go and read
news.announce.newgroups.

I always expect that, when people do this, if the quoted poster feels
they've been misquoted they'll speak up, as you have now done.

However I'm afraid I still fail to see the difference which the word
`continuing' makes to the meaning of your sentence.

I don't see the difference between asking `why SysV semantics were
created for the /tmp directory' (interpreting this sentence as close
as possible to something reasonable) and asking `why SysV semantics
are required for the /tmp directory', or indeed `why SysV semantics
are still required for the /tmp directory'.

>> Now, in general, if we adopt the private groups scheme the most
>> important part of the ownership of a file will no longer be the
>> user ownership but the group ownership,
>>
>> My first argument in this message against BSD semantics in /tmp
>> is that this violates the general rule in my previous paragraph. 
> 
> This is a rather arbitrary rule, which ignores the fact that only the
> owner of a file can chmod its permissions.

It's not an arbitrary rule, it's a rule derived from observation.

Your point about chmod is irrelevant; a user who does not own the file
but can write it and the containing directory (this is the usual case
- remember, I said `most important', not `only important') can easily
replace the file with another with the same contents owned by
themselves.  In almost all circumstances this will have the same
effect as a chmod.

>> My second argument in this message against BSD semantics is that
>> it is generally less expected than System V semantics.
> 
> About as unexpected as setgid bits on directories, Ian.

Setgid bits on directories are *visible* directly.  BSD semantics are
only visible by their effect (and by looking in the fstab).

BSD semantics do things behind your back; setgid directories do it up
front where you can see it and turn it on and off.

Things that do things behind your back are usually much less expected
than those that give an indication of their presence.

>> When using SysV semantics the setgid bit gives you a clear
>> indication that something is happening to the group ownerships
> 
> It is only clear if you look, and know about setgid.

If you don't look you won't see the group ownerships at all -
presumably in that case you don't care at all.  If you don't know
about setgid finding out is not hard.

> You are advocating a mix of SysV and BSD and claiming it will have a more
> expected behaviour?

I am advocating an *explict* specification of the semantics of each
directory rather than an *implicit* specification in the fstab.

Any software engineer and user interface designer will know how
important explicitness is.

More explict specification produces expected behaviour more often,
because the specification is visible before the behaviour.

> To find out the group ownership of a created file under setgid:
>   1) ls -ld ..

You mean `ls -ld .'

>   2) Check the setgid bit.
>   [interpret the results]
> 
> Under BSD mount, it is simply:
> 
>   1) The group of the created file is always the same as the group of the
>      directory.

You have forgotten the requirement to look in the fstab.  You must
count that in the instructions for BSD mount.  Since BSD semantics
have been unusual in the Linux community so far and are unobvious to
newcomers to Unix you'll probably find that most people don't look in
the fstab.

The obvious place to look for information about what is going to
happen is to look nearby - in this case at the permissions of the
directory and the ids of the process.  Looking at the fstab is a bad
thing in this context, because it is not the obvious place except for
refugees from BSD systems.


Here starts the response to Stephen White's message entitled
"PRIVATE GROUPS 2/2"  (there is no need to shout, incidentally).
I have not omitted anything from the start of the quoted text here -
all the context that Stephen White provided is visible.

Stephen White writes:
} [Ian Jackson writes:]
}} Stephen White writes:
>>> Can you explain how BSD managed all these years if SysV semantics
>>> are such a requirement for /tmp?
>>
>> Neither of the two arguments I make above apply in a traditional
>> BSD system with a umask of 022 or similar. The first argument
>> doesn't apply because group ownership is generally irrelevant on
>> such a system - access is controlled by user ownership.
>
> This argument relies on your arbitrary rule being accepted as fact.

This is a very interesting comment.  Unfortunately the context is
somewhat missing.

>> The second argument doesn't apply for this reason as well,
>
> And hence also relies on accepting your arbitrary rule as fact.

The `arbitrary rule' referred to is:
}} Now, in general, if we adopt the private groups scheme the most
}} important part of the ownership of a file will no longer be the
}} user ownership but the group ownership,

As I explain above, this is not an `arbitrary rule' but an
observational one.

The `two arguments' in the part of my text quoted above are that the
paragraph above fails to be true for /tmp if it has BSD semantics,
which is inconsistent, and that the setgid bit gives you clear
indication that something weird is going on - this indication being
missing when BSD semantics are used.

> Despite this, it still remains irrelevant if the group ownership is
> "fred" or "root" in the /tmp directory.
> 
> [description of how the effect on people's capabilities is the same]

My arguments are not based on an incorrect effect on people's
capabilities but on the fact that BSD semantics in /tmp are less
intuitive (both compared with the rest of the filesystem under umask
022 and in general) than SysV semantics, especially seeing as the
setgid bit isn't set to flag that something odd is happening.

>> and also because `ls' doesn't show the group ownership by default
>> on BSD, thus hiding the unexpected behaviour (out of sight, out
>> of mind).
> 
> Weak.

Not at all.  On BSD systems the group permissions are almost always
irrelevant - why do you think BSD ls doesn't show the group ownership?
Therefore, on BSD systems the unexpected behaviour is irrelevant not
just because it doesn't make a difference to people's actual
capabilities, but because the unexpectedness affects something that
noone cares about anyway.

>>> The fact remains that uid=gid is merely a disguised BSD filing
>>> system.
>>
>> uid=gid has nothing to do with it.
> 
> I am aware of that. I was using the common name that has been applied to
> the argument. Your personal prejudice against the name shouldn't prevent
> you from understanding what I am saying.

I am not `personally prejudiced' against the name; it is technically
inaccurate.

> I had not addressed the issue of making gid numbers equal uid numbers in
> my entire message, so your misunderstanding is difficult to comprehend.

Well, I'm sorry, but I've made precisely the opposite mistake when
responding to Remy Card - because people like you are being imprecise
in your use of terminology.

I shall now answer your argument as restated:
> ... Setgid bits on directories [are] merely a disguised BSD
> filing system.

Quite on the contrary: setgid directories are a BSD filing system made
both visible and flexible.  I would say that mounting a filesystem
with BSD semantics is merely a disguised and inflexible way of getting
the effect of setgid directories.

>>> Incorrect. The one argument against mounting with BSD consituted
>>> of "What happens if the admin sees the parameter in fstab and
>>> removes it?".
>> 
>> You have obviously not been reading the list.
> 
> Would you understand if I rephrased it to: "The one significant argument
> against..."? This is unbearably misusing the word "significant", I admit.

I didn't fail to understand it the first time.  Unfortunately what you
said the first time was false as a matter of fact.  Please do not try
to blame me for your inability to phrase things correctly.

What you say this time is false as a matter of opinion.

> [Matthew Hannigan wrote:]
>]         1. You can't get back the V7 semantics back for
>]                 individual directories.
> 
> You haven't explained why this is important.

I have given one example of an area where it is useful - /tmp.

In general it is better to remain flexible.  There is no good reason
for cutting off one's options here.

>> 4. It violates the principle of least surprise.  Files will be
>> created (with a umask of 002, remember) with odd group ownership
>> for no readily apparent reason.
> 
> I have already dealt with the fallacy of your argument of "least
> surprise".

No, you haven't.  You wrote (I think this is what you're referring to,
and again I've wrapped it to fit):
>>>   The principle of least surprise means that (as much as possible)
>>> you get a consistent and known result, whatever that result is and
>>> no matter where you are.

No, the principle of least surprise means exactly what it says: that
you should, where possible, try to minimise the amount of surprise.

One way of reducing surprise is to reduce the number of different
possible things that can be done - thus the outcome becomes easily
known.  However, Unix has had a long history of flexibility.  What one
should seek to do instead is to make the differences in behaviour as
explicit as possible in the request to and/or initial state of the
system.

Remember that the most consistent thing in general is SysV semantics
unmodified by the setgid bit: it preserves consistency between the
behaviour of uids and gids, and actually has *less* behaviour (ie, it
does less).  It is better to make the request to go to a more
complicated behaviour visible - that will mean that when the behaviour
takes place the user is more likely to be expecting it.

}} The question is really which [of per-directory or per-(file)system
}} selection of group inheritance] is most likely to be required, and
}} how much effort it is to work around if one needs something
}} that's not provided.
}} ...
}}
>> In practice, I don't think that many sysadmins would bother
>> turning it off even if we made it easy by mounting everything
>> bsd-style.
> 
> And here, you go against your own argument.

No, here you once again fail in reading comprehension.

I was following on from my paragraph `the question is' (which you
apparently failed to realise was relevant) by stating that
per-directory selection is more likely to be required than per-system
and/or per-filesystem selection, because the latter is unlikely to be
required at all.

>> I think you would benefit from reading the alt.atheism FAQ file
>> on how to construct a logical argument.  It can be found on
>> rtfm.mit.edu in /pub/usenet/news.answers/atheism/logic.
> 
> By now it should be obvious that you need to read this more than I do.
> Skimming through one of my text books, I find the flaws in your arguments
> have the following names:
>
> 1) Circulus in probando.  [definition omitted]

Where have I used a circular argument ?  A bald assertion at the end
of a lengthy debate is nowhere near sufficient to demonstrate my
alleged error.

> 2) The fallacy of sophistical refutations.  ["Straw man"]

Again, it is not sufficient merely to claim that I am attacking a
straw man.  You must point to the specific location of my supposed
attack on a position you do not hold, and preferably show how the
position you do hold differs from that I am attacking.

In general it would seem to me more likely that you have merely failed
to express yourself clearly - you have certainly done so on several
occasions and then attempted to lay blame on me for interpreting what
you wrote as what you meant.

> If it can be demonstrated that SysV semantics are required and the
> benefits outweigh the extra complexity of a mixed BSD/SysV filing system,
> then, by all means, setgid is the way to go, otherwise there is no
> purpose in complicating things unnecessarily.

The extra `complexity' is not just complexity - it is flexibility and
visibility.

Flexibility is in general useful; don't rule out making it possible to
do something merely because it's "complicated" to specify whether to
do it or not - if the original designers of Unix had thought that way
Unix wouldn't be the programmers' refuge that it is.

Visibility is useful because it means that people are more likely to
see what is causing a particular behaviour.  This allows them both to
expect the behaviour in advance and to take advantage of the
flexibility I mention above if they wish to turn it off.

--
Ian Jackson, at home  <ijackson@nyx.cs.du.edu> or <iwj10@cus.cam.ac.uk>
Cambridge University Computer Laboratory, Security Group
PGP2 public key available on server.  Urgent email: <iwj@cam-orl.co.uk>

From debian-devel@pixar.com Sat Mar 26 18:04:27 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA06368; Sat, 26 Mar 94 18:04:24 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkhJc-0006Bea; Sat, 26 Mar 94 14:58 PST
Date: Sat, 26 Mar 94 14:58 PST
Message-Id: <9403262258.AA26665@spectrum.cs.bucknell.edu>
Errors-To: bruce@pixar.com
Reply-To: quinlan@spectrum.cs.bucknell.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan)
To: debian-devel@pixar.com
Subject: Re: default editors
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


bruce <bruce@beagle.pixar.com> writes:

> I suggest that Debian support a symbolic link "/usr/bin/editor", which
> is the default editor for all programs. Which editor that points to is
> set up by the install scripts in response to a prompt, and can be
> easily modified by the system admin at any time.

The $EDITOR variable is quite adequately supported by most software and
there is absolutely no need to put in a symlink for "editor".
Especially since beginners should know what editor they are in (the one
they type in on the command line or have in their $EDITOR variable).

> On the topic of default editors, having a single default, one that is
> good for _beginners_ is a good idea, but beyond that why does anyone
> care about the default? I take for granted that any decent application
> would honor the value of my $EDITOR variable.

ed/ex/vi are the only editors which should be considered default on a
UNIX system.  /bin/ed is for emergencies and /usr/bin/ex and /usr/bin/vi
are for non-emergencies.

I also retrieved the new vi (`nvi') from BSD 4.4 and compiled it under
Linux.  It works much nicer than elvis, but it is entirely unsuited for
a boot/root disk since it is something like 300k in size.

> For those beginners, one of the "arrow keys move around, delete key
> deletes the character under the cursor, typing is inserted to the
> right of the cursor" editors would be best. Is that what "pico" is?

More or less.  However, it has a number of Emacs-ish key bindings (C-n,
C-p, C-a, C-e, and so forth) that make it tolerable for people like me.

Pico shouldn't be default, but it should be say, "recommended" for
systems with beginner users.  BTW, `pico' comes with PINE (probably the
best mail system for beginners).

Dan

--
Daniel Quinlan  <quinlan@spectrum.cs.bucknell.edu>

From debian-devel@pixar.com Sun Mar 27 00:18:53 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01347; Sun, 27 Mar 94 00:18:49 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkn9x-00065Ba; Sat, 26 Mar 94 21:13 PST
Date: Sat, 26 Mar 94 21:13 PST
Message-Id: <9403270928.A4322wk@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: stephen.white@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: stephen.white@adam.com.au
To: debian-devel@pixar.com
Subject: NEW PROPOSAL
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


 
I would like to present a new idea for 'private groups'.
 
First, I'd like to give my understanding of the situation to be sure I
have it completely right.
 
Typical system:
  /home
  /home/fred (fred,users)
  /home/jack (jack,users)
  /home/jill (jill,users)
  /home/proj (root,proj)
 
jack and jill are members of "proj". If they want to work in the
/home/proj directory, they can type "newgrp proj".
 
If they leave their umask at one value (022, 020, 002, 007) for both
their home directories and /home/proj, then fred can read (and
possibly write) to their home directories through the "users" group.
 
To avoid this, jack and jill have to remember to set the umask to the
appropriate value every time they change working directories.
 
The current proposal:
  /home
  /home/fred (fred,fred)
  /home/jack (jack,jack)
  /home/jill (jill,jill)
  /home/proj (root,proj)
 
Accessing the /home/proj directory remains unchanged.
 
Providing users with their own groups allows them to leave the umask
set at one value since they are the only member of their own group.
 
This prevents fred from using the group permissions to access jack or
jill's files, whilst still letting them share files in the project
directory (without stuffing around with umask).
 
My proposal:
  /home
  /home/fred (fred,private)
  /home/jack (jack,private)
  /home/jill (jill,private)
  /home/proj (root,proj)
 
Accessing the /home/proj directory remains unchanged.
 
Users are listed in /etc/passwd as being in the group "users", the
same as the "Typical system" above. The group "private" is listed in
/etc/group with no members.
 
Files created in users home directories will have the group ownership
of "private". Since nobody belongs to the "private" group, fred
cannot use the group permissions to access jack or jill's files.
 
It isn't necessary to belong to a group for that group ownership to
be inherited from the parent directory. This is the point that makes
my proposal possible.
 
This arrangement with the single "private" group eliminates the need
to have a group per user, and therefore eliminates the need to
synchronise /etc/password and /etc/group with a scheme like uid=gid.
 
This in turn eliminates the extra problems with NFS mounting and most
of the other objections that have been raised against private groups,
whilst still retaining the same usage and all the benefits that
private groups offered.
 
Furthermore, someone has been very clever and prevented chmod from
setgid'ing a file if you do not belong to the group (even if you do
own the file). This eliminates that possible security hole.
 
Any comments?
 

From debian-devel@pixar.com Sun Mar 27 00:19:31 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01386; Sun, 27 Mar 94 00:19:28 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pknAa-00064ia; Sat, 26 Mar 94 21:13 PST
Date: Sat, 26 Mar 94 21:13 PST
Message-Id: <9403270928.A4323wk@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: stephen.white@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: stephen.white@adam.com.au
To: debian-devel@pixar.com
Subject: RCS DEBATE
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


 
[The following is written by Chris Adlard, the software configuration and
 quality manager for two of the largest software projects in Australia.  ]
 
  Having read the discussion for several days now, I would like to add my
comments.
 
 IJ> Remy Card's championing of RCS to solve the world's problems have
 IJ> been clearly shown to be a red herring by David Engel.
 
  I put it to you that no such thing has been done. The following is what
David Engel said.
 
 DE> Remy, you're thinking too much like a software person.  Not every
 DE> shared project involves a repository of source code that can benefit
 DE> from using a version control system (VCS).
 DE> 
 DE> One example is a group of users that need access to shared database.
 DE> The DBMS prevents users from trashing each other's entries by locking
 DE> individual records as needed.  However, users still need write access
 DE> to the database.
 DE> 
 DE> Another example is going to be done in Debian 0.92.  Ian is setting
 DE> things up so any member of group `staff' can install packages in
 DE> /usr/local.  Surely you're not suggesting that the binaries from
 DE> /usr/local/bin be placed under VCS, are you?
 
  David Engel is right, however Remy Card was correcting you on a
completely different issue. The following is the original material to
which he was responding.
 
 IJ> This scheme solves a serious problem, namely that directories for
 IJ> group projects are quite simply unmanageable without it.
 IJ> 
 IJ> I have often been in the position of having to do cp -r on large
 IJ> directory trees because I couldn't update the appropriate portions.
 IJ> Numerous times I have had to 'make clean' before I could 'make',
 IJ> because some of the '.o' files were unreadable and some were
 IJ> unwriteable.
 
  As is now obvious, you were making a clear and specific reference to
code. David Engel in no way has shown Remy's debunking of the above to be
a "red herring".
 
  Remy Card is quite correct when he says that a revision control system
must be used on any software project. I fully endorse his comments. Ian 
Jackson's suggestion of using groups for project work is not a viable 
proposition.
 
  Revision control should be used for both development libraries and
product libraries. Development libraries are usually controlled by the
team leader.
 
  After unit testing, product libraries are used. These are formally
controlled by the configuration manager, who is the _only_ person
authorised to change the code.
 
  Revision control systems keep a record of all versions of the code from
the beginning of the project. Fixed sets of code versions for baselines
and releases are 'tagged' for identification. If an earlier version or
release is needed, it is available.
 
  Various methods of locking out multiple developers are used. Some of the
more sophisticated CM packages have built-in locking mechanisms. We are
currently using CVS, a front end to RCS, and have scripts to enable
booking files out to a user, locking out other users, and submitting code
back for approval. Changes must be processed very quickly to free the code
for other developers.
 
  Groups can be used for information that can be shared with no risk of
confusion, such as specifications, informal lists etc. This also applies
to software like databases which have their own built-in locking
methods.
 
  However, this does not apply to _code_. It can never be assumed that a
piece of code will not be changed by more than one person. It is necessary
to be able to define the current state of a project at any time. If you
don't have adequate revision control, then you usually don't have a
project.
 
  Some people may argue against locking out other users, saying that there
are no problems with parallel development or with using the concurrent
versions capabilities of packages like CVS. Parallel development can be
managed under some circumstances, but the risks outweigh the advantages
and it can become a nightmare to control. No package can determine if
merged code is functionally intact - inspection by an engineer is always
necessary.
 
  If anyone wants to challenge me on the use of revision control systems,
I would like to say that I have been a configuration manager/quality
control manager for the last eight years. This has involved large projects
with forty to fifty programmers changing up to four thousand items of
code, often at geographically diverse sites.
 
Summarising; even a very small project should use revision control, with
CM activites scaled down accordingly to suit.
 

From debian-devel@pixar.com Sun Mar 27 01:05:35 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01454; Sun, 27 Mar 94 01:05:32 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pknt9-0005qpa; Sat, 26 Mar 94 21:59 PST
Date: Sat, 26 Mar 94 21:59 PST
Message-Id: <199403270602.WAA07356@beagle.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: bruce@beagle.pixar.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: bruce@beagle.pixar.com
To: debian-devel@pixar.com
Subject: Moderation ON
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

The debian-devel and debian-user lists have moderation turned ON for the
next few days. This is due to a small, unusual, and probably
out-of-character glitch on debian-devel.

These lists must always be used in a polite and decorous fashion,
without exception.

	Bruce Perens

From debian-devel@pixar.com Sun Mar 27 01:11:37 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01506; Sun, 27 Mar 94 01:11:34 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pknz0-0006Woa; Sat, 26 Mar 94 22:06 PST
Date: Sat, 26 Mar 94 22:06 PST
Message-Id: <9403270603.AA23745@then.midnight.com>
Errors-To: bruce@pixar.com
Reply-To: birkholz@midnight.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: birkholz@midnight.com (Matt Birkholz)
To: debian-devel@pixar.com
Subject: NEW PROPOSAL
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Sat, 26 Mar 94 21:13 PST
   From: stephen.white@adam.com.au

   I would like to present a new idea for 'private groups'.

   First, I'd like to give my understanding of the situation to be sure I
   have it completely right.

   [...]

Right!

   My proposal:
     /home
     /home/fred (fred,private)
     /home/jack (jack,private)
     /home/jill (jill,private)
     /home/proj (root,proj)
      ^^^^--------------------Is this kosher (according to FSSTND)?

   [...]

   This arrangement with the single "private" group eliminates the need
   to have a group per user, and therefore eliminates the need to
   synchronise /etc/password and /etc/group with a scheme like uid=gid.

There was never a "need" to "synchronize" /etc/passwd and /etc/group.  That
was an aesthetically motivated choice.

Your scheme adds the requirement that home directories be setgid=private,
yes?  It would seem that there is a tradeoff: eliminate a group per user,
or eliminate setgid home directories.  (I don't really care which is
chosen.)

   This in turn eliminates the extra problems with NFS mounting and most
   of the other objections that have been raised against private groups,
   whilst still retaining the same usage and all the benefits that
   private groups offered.

I don't see this.  I think you've added a possible objection while
eliminating one.  What are the "extra problems" with NFS mounting?  Don't
you have to copy the site's /etc/passwd and /etc/group in either case?

   Furthermore, someone has been very clever and prevented chmod from
   setgid'ing a file if you do not belong to the group (even if you do
   own the file). This eliminates that possible security hole.

This sounds like a source of confusion, e.g.: how come I can't make this
file, that I mistakenly created in /usr/proj, private?
	$ chgrp private file
didn't work!

Interesting idea, though.

Matthew Birkholz
birkholz@martigny.ai.mit.edu

From debian-devel@pixar.com Sun Mar 27 01:21:37 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01520; Sun, 27 Mar 94 01:21:34 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pko8f-0005pea; Sat, 26 Mar 94 22:16 PST
Date: Sat, 26 Mar 94 22:16 PST
Message-Id: <9403270613.AA03718@spiff.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: new adduser - please test
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Appended are the files /usr/sbin/adduser and /etc/default/adduser from
Debian 0.92.  I have just updated adduser in several ways, including
support for the project group idea.  I have not had much time to test
it (I'm working the 11-8 weekend shift now... :/).  I need to know how
well it works, so please test it thoroughly and let me know how it can
be improved.  Feel free to improve it yourself and mail me your
changes.

--- cut here: /usr/sbin/adduser ---
#! /bin/sh
#
# adduser 1.1: a utility to add users to the system
#
# Copyright (C) 1993, 1994 Ian A. Murdock <imurdock@gnu.ai.mit.edu>
#
#    This program is free software; you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation; either version 2 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program; if not, write to the Free Software
#    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#

# Everything happens too fast, so don't let the user interrupt.  We
# certainly don't want a half-done job.
trap "" 1 2 3 15

# Set a few important variables before getting started.
NUMARG=$#
LOGIN="$1"
EXIST=0

PASSWD="/etc/passwd"
GROUP="/etc/group"
PBAK="/etc/passwd-"
GBAK="/etc/group-"

PLOCK="/etc/ptmp"		# Standard method of locking the password file.
				# Is there a ``standard'' method of locking the
				# group file?

DEFAULTS="/etc/default/adduser"

# This is a bit tricky.  If method is "default" and there are no users in the
# default group, then add the user to the group in $GROUP without a leading
# comma.  If there are, then add the user to the group in $GROUP preceded by
# a comma.  If method is "project", then simply create the new group and add
# the user to it.
add_to_group()
{
	if [ $METHOD = "default" ]; then
	 # First of all, determine the name of the group.
	 GROUP_NUM=$1
	 GROUP_NAME=`grep "::$GROUP_NUM:" $GROUP | cut -f 1 -d ":"`
	 echo -n "($GROUP_NAME)... "
	 grep -x "^$GROUP_NAME::$GROUP_NUM:$" $GROUP >/dev/null 2>&1
	 if [ $? = 0 ]; then
	 	sed "/^$GROUP_NAME/s/\$/$LOGIN/" $GROUP > /tmp/group
	 else
	 	sed "/^$GROUP_NAME/s/\$/,$LOGIN/" $GROUP > /tmp/group
	 fi
	 if [ -f /tmp/group ]; then
	 	cp $GROUP $GBAK
	 	mv /tmp/group $GROUP
	 fi
	else
	 # Note that arguments are completely ignored in this case.
	 echo -n "($LOGIN)... "
	 cp $GROUP $GBAK
	 echo "$LOGIN::$NUID:$LOGIN" >> $GROUP
	fi
}

# What do we do if $DEFAULTS doesn't exist? 
no_defaults ()
{
	DSHELL="/bin/bash"
	DHOME="/home"
	SKEL="/etc/skel"
	SPOOL="/var/spool/mail"
	METHOD="default"
	FIRST_UID=1000
	USERS_GID=1000
}

# Make sure that we can add $LOGIN to the system.
if [ `whoami` != "root" ]; then
	echo "$0: only root may add users to the system." ; exit 1
fi
if [ $NUMARG = 0 ]; then
	echo "$0: you need to specify the login to add;"
	echo "for example, \`$0 imurdock'."
	echo "The default variables are defined in the file $DEFAULTS."
	exit 1
fi
id $LOGIN >/dev/null 2>&1 && EXIST=1
if [ $EXIST = 1 ]; then
	echo "$0: the login $LOGIN already exists." ; exit 1
fi
if [ -f $PLOCK ]; then
	echo "$0: $PASSWD is locked.  Try again later." ; exit 1
fi

# Okay, we can.
cp $PASSWD $PLOCK

# And now the program begins.
if [ -f $DEFAULTS ]; then
	echo -n "Reading in $DEFAULTS..." ; source $DEFAULTS ; echo "done."
else
	echo "No defaults file found.  Using built-in defaults." ; no_defaults
fi

echo "" ; echo -n "Looking for first available UID..."
NUID=`cat /etc/passwd | sed /^nobody:/d | cut -f 3 -d ":" | sort -n | \
	tail -1` ; NUID=`expr $NUID + 1`
if [ $NUID -lt $FIRST_UID ]; then
	NUID=$FIRST_UID
fi
if [ $METHOD = "default" ]; then
	NGID=$USERS_GID
else
	if [ $METHOD = "project" ]; then
		NGID=$NUID
	else
		echo -e "\n$0: unknown method \`$METHOD'."
		rm -f $PLOCK ; exit 1
	fi
fi
echo "done.  Using UID $NUID and GID $NGID."

if [ $NUID = 0 -o $NUID -gt 65535 ]; then	# _Definitely_ don't want that!
	echo ""
	echo "$0: Ack!  Something went wrong!  Aborting!"
	echo ""
	rm -f $PLOCK
	exit 1					# _Big_ time...
fi

echo "" ; echo -n "Adding login $LOGIN..."
echo "$LOGIN:*:$NUID:$NGID::$DHOME/$LOGIN:$DSHELL" >> $PLOCK
cp $PASSWD $PBAK
mv $PLOCK $PASSWD
echo "done."

echo "" ; echo -n "Adding $LOGIN to group $NGID "
add_to_group $NGID
echo "done."

echo "" ; echo -n "Creating home directory: $DHOME/$LOGIN..."
if [ -d $DHOME/$LOGIN ]; then
	echo -e "\n*** $DHOME/$LOGIN already exists!  Not copying files from $SKEL. ***"
else
	mkdir $DHOME/$LOGIN
	if [ $METHOD = "project" ]; then
		chmod 775 $DHOME/$LOGIN ; chown $NUID.$NGID $DHOME/$LOGIN
	fi
	cp -i $SKEL/.[a-z]* $SKEL/* $DHOME/$LOGIN >/dev/null 2>&1
	if [ $METHOD = "project" ]; then
		test -f $DHOME/$LOGIN/.bashrc && \
		 ( sed "s/umask 022/umask 002/" $DHOME/$LOGIN/.bashrc > \
		   /tmp/.bashrc ; mv /tmp/.bashrc $DHOME/$LOGIN/.bashrc )
		test -f $DHOME/$LOGIN/.profile && \
		 ( sed "s/umask 022/umask 002/" $DHOME/$LOGIN/.profile > \
		   /tmp/.profile ; mv /tmp/.profile $DHOME/$LOGIN/.profile )
		test -f $DHOME/$LOGIN/.login && \
		 ( sed "s/umask 022/umask 002/" $DHOME/$LOGIN/.login > \
		   /tmp/.login ; mv /tmp/.login $DHOME/$LOGIN/.login )
	fi
	# Probably will never happen, but just in case... we don't want all
	# files on the system to be `chown'ed to $NUID.$NGID!
	if [ "$DHOME/$LOGIN" != "/" ]; then
		chown -R $NUID.$NGID $DHOME/$LOGIN
	fi
	echo "done."
fi

echo -n "Creating mailbox: $SPOOL/$LOGIN..."
touch $SPOOL/$LOGIN ; chmod 660 $SPOOL/$LOGIN ; chown $NUID.mail $SPOOL/$LOGIN
echo "done."

passwd $LOGIN
chfn $LOGIN

# EOF
--- end: /usr/sbin/adduser ---

--- cut here: /etc/default/adduser ---
# The DSHELL variable specifies the default login shell on your system.
DSHELL="/bin/bash"

# The DHOME variable specifies the directory containing users' home
# directories.
DHOME="/home"

# The SPOOL variable specifies the directory containing users' mailboxes.
SPOOL="/var/spool/mail"

# The SKEL variable specifies the directory containing `skeletal' user
# files; in other words, files such as a sample .profile that will be
# copied to the new user's home directory when it is created.
SKEL="/etc/skel"

# The METHOD variable can be either "default" or "project".
METHOD="default"

# FIRST_UID should be the first UID for users on your system.  UIDs below
# FIRST_UID are reserved for administrative and system accounts.
FIRST_UID=1000

# USERS_GID should be the GID of the group `users' (or the equivilant
# group) on your system.
USERS_GID=100
--- end: /etc/default/adduser --

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Sun Mar 27 01:34:14 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01572; Sun, 27 Mar 94 01:34:12 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkoKt-0006Bra; Sat, 26 Mar 94 22:28 PST
Date: Sat, 26 Mar 94 22:28 PST
Message-Id: <9403270626.AA23755@then.midnight.com>
Errors-To: bruce@pixar.com
Reply-To: birkholz@midnight.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: birkholz@midnight.com (Matt Birkholz)
To: debian-devel@pixar.com
Subject: RCS DEBATE
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Sat, 26 Mar 94 21:14 PST
   From: stephen.white@adam.com.au

   [The following is written by Chris Adlard, the software configuration and
    quality manager for two of the largest software projects in Australia.  ]

     Having read the discussion for several days now, I would like to add my
   comments.

    IJ> Remy Card's championing of RCS to solve the world's problems have
    IJ> been clearly shown to be a red herring by David Engel.

     I put it to you that no such thing has been done. The following is what
   David Engel said.

   [...]
     David Engel is right, however Remy Card was correcting you on a
   completely different issue. The following is the original material to
   which he was responding.

A completely different issue would be a red herring.

    IJ> This scheme solves a serious problem, namely that directories for
    IJ> group projects are quite simply unmanageable without it.
    IJ> 
    IJ> I have often been in the position of having to do cp -r on large
    IJ> directory trees because I couldn't update the appropriate portions.
    IJ> Numerous times I have had to 'make clean' before I could 'make',
    IJ> because some of the '.o' files were unreadable and some were
    IJ> unwriteable.

     As is now obvious, you were making a clear and specific reference to
   code. David Engel in no way has shown Remy's debunking of the above to be
   a "red herring".

It's obvious, huh?  Where did Remy debunk the fact that, under the
traditional arrangement, .o files are often (by default) inappropriately
write protected?  Where did Remy debunk the fact that there exist other
types of files, revisions of which cannot be controlled by RCS
(e.g. database files)?  Where did Remy debunk the fact that it would be
more convenient not to have to _fix_ the permissions of RCS directories
created in a project directory tree?  These are the problems which the
proposed private group proposal was intended to address.  What does RCS
have to do with these problems?

     Remy Card is quite correct when he says that a revision control system
   must be used on any software project. I fully endorse his comments. Ian 
   Jackson's suggestion of using groups for project work is not a viable 
   proposition.

I fully endorse Remy's comments that a revision control system should be
used when possible.  Ian's suggestion was NOT, I repeat, NOT to replace
RCS.  Controlling revisions to source files is a different issue.  (The red
herring wins again.)

   [...]

Thanks for the tutorial on revision control (not).

   Summarising; even a very small project should use revision control, with
   CM activites scaled down accordingly to suit.

I agree wholeheartedly.

Is someone disagreeing with you?

Can we put this red herring to bed, please?

Matthew Birkholz
birkholz@martigny.ai.mit.edu

From debian-devel@pixar.com Sun Mar 27 01:40:12 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01620; Sun, 27 Mar 94 01:40:10 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkoQf-0006ANa; Sat, 26 Mar 94 22:34 PST
Date: Sat, 26 Mar 94 22:34 PST
Message-Id: <9403270632.AA23761@then.midnight.com>
Errors-To: bruce@pixar.com
Reply-To: birkholz@midnight.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: birkholz@midnight.com (Matt Birkholz)
To: debian-devel@pixar.com
Subject: default editors
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Sat, 26 Mar 94 14:58 PST
   From: quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan)

   [...]
   ed/ex/vi are the only editors which should be considered default on a
   UNIX system.  /bin/ed is for emergencies and /usr/bin/ex and /usr/bin/vi
   are for non-emergencies.

Interesting opinions, Daniel.  Want to know what I think?  (Not fair; I
read _your_ blundering generalizations.)

I think Emacs should be the default on a GPL'ed and largely GNU
distribution.

No, I'm not starting anything.  At least, I promise not to _continue_ this
thread.

   [...]
   More or less.  However, it has a number of Emacs-ish key bindings (C-n,
   C-p, C-a, C-e, and so forth) that make it tolerable for people like me.

Blasphemy!

Is the religious and facetious nature of my reply clear enough, or do I
have to spell it out?

Matthew Birkholz
birkholz@martigny.ai.mit.edu

From debian-devel@pixar.com Sun Mar 27 07:54:44 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01738; Sun, 27 Mar 94 07:54:41 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkuH6-0006AQa; Sun, 27 Mar 94 04:49 PST
Date: Sun, 27 Mar 94 04:49 PST
Message-Id: <9403271247.AA23808@polyhymnia.iwr.uni-heidelberg.de>
Errors-To: bruce@pixar.com
Reply-To: Helmut.Geyer@iwr.uni-heidelberg.de
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Helmut Geyer <Helmut.Geyer@iwr.uni-heidelberg.de>
To: debian-devel@pixar.com
Subject: The X11 package for Debian (long)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Hello all!

Here is a proposal, what is to be included in the X11 distribution
and/or contrib packages using X11.
Some of these will probably be covered by some other packages. If so,
please mail me about it (some things are cleared already, but I will 
list those here again to have the complete picture). Those people I 
could see on the latest developing list may be working on some of these.
If you are working on something of this list and are not noted, please 
contact me.

There are a lot of questions within this, so please answer them.
Questions are indicated by a leading question mark.
Any other comments are very welcome, too.

If you are missing something that is of general interest or if you find
something obsolete, feel free to complain.

Leading # means that this package should be there, but is IMHO not 
placed rightly in the X11 packages. Mostly a more proper location
is pointed out.
Leading R means that I think of this part as required to run X11.

So here is what I want to see (any help with this project is appreciated).

The basis packages (=that's what I want in the distribution):

- XFree86 category:
      complete XFree86 2.1 distribution (I would like to have it like 
      this, nothing added, nothing left out) without servers and LinkKit.

- Xservers category: All servers and the LinkKit including a hga server.

- X11 (requires XFree86 & Xservers) category:
     - windowmanagers (wm):
R           fvwm (this should be the standard wm), including pixmaps and
                   configuration scripts.
?       Is there need for other wm choices (besides olvwm that comes with the
?       xview contrib package)? I can provide ctwm, piewm and gwm as well,
?       but do not like them as well.
     - small utilities for X11:
R           colour and ansi Xterm, rxvt & needed fonts
#R          the svgalib restore/save commands (they are missing in the 
                      vgalib package of 0.91, but should go there). 
R           xlock
R           XConsole from procps
            xinfo (only if no emacs present)
            xcalender
            xpalette
 
     - additional libraries :
R        libXpm (at present version 3.3, haven't tried 3.4 yet) including 
                the pixmap editor pixmap 2.4.
         libgr (at present only needed for xv, but I think it should be 
                in the distribution).

- X11 developer category :
?     Do we want to keep the shared and the static/stub libraries in one 
?     package or do we want to split them up and put the static/stubs into 
?     this category? I want to be able to compile anything I can run on the 
?     system by myself without installing a second package, but it takes
?     a lot of disk space to have the static/stubs and headers around.
      - fwf free widget foundation libraries.
      - xxgdb
      - ups

- tinyX (requires XFree86 & Xservers) category:
     package for X11 on systems with small memory.

- X / TeX category:
      xdvik, bibview, xtexcad, transfig 
#     TeXshell  (needs tcl/tk) should -> contrib-tcl/tk

- X11 graphics category ( this intersects what J. Robinson is doing)
      these are things I would like to have in the distribution, not in a 
      contrib package:
     - xfig 
     - ghostview (requires gs with X11 support)
     - xv 3.00a patched for gzip (this is Shareware and should therefore
       perhaps go into the contrib package, though it is very useful).
       inluded some demo pictures (logos in different formats, Linus GIFs)
       (requires gs with pbmraw support)
     - gnuplot (x11 only)
     - netpbm 

- X11 mail & news:
     - Mumail
     - mailx (-> svalente@athena.mit.edu)
     - xmailtool
     - xrn
     
- X11 connectivity:
     xarchie, xgopher, xftp
     seyon (-> porterm@er4.eng.ohio-state.edu)

- X11 editors: 
     - emacs (-> Dan Quinlan, own package)
     - aXe 6.1
?        are there other editors needed? I use emacs only, so I couldn't 
?        know...

The contrib packages:

- X11 desktops (listed as contrib, as none of these is that good that I would
          want to work with it by default):
    xfilemanager, xdesk, xdtm

- Mosaic:
      Mosaic 2.2 statically and dynamically linked to libXm
      Mosaic for term connections.
?          I cannot do this as I do not have Motif. I would like to
?          see it, though. Anyone?

- X11 games (-> talvola@fennel.berkeley.edu)

- Interviews
?          where is interviews to reside? I'm not up to date with the 
?          fsstnd discussion on themes like that. If there are no
?          objections I will put the  external binaries and manpages into the 
?          appropriate subdirs of /usr/X386 and the rest into 
?          /usr/X386/lib/Interviews

  Thank you for reading,

		Helmut

------------------------------------------------------------------------------
Helmut Geyer                                Helmut.Geyer@iwr.uni-heidelberg.de

From debian-devel@pixar.com Sun Mar 27 09:04:46 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01805; Sun, 27 Mar 94 09:04:43 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkvMs-0005p0a; Sun, 27 Mar 94 05:59 PST
Date: Sun, 27 Mar 94 05:59 PST
Message-Id: <Pine.3.89.9403261115.B49-0100000@budge.apana.org.au>
Errors-To: bruce@pixar.com
Reply-To: charlieb@budge.apana.org.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: <charlieb@budge.apana.org.au>
To: debian-devel@pixar.com
Subject: Re: Guidelines
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


On Thu, 24 Mar 1994, Davor Cubranic wrote:

> Why not use joe instead of pico as a 'user-friendly' editor?  It
> is similar to wordstar/Borland editors, so I'd imagine a lot of
> people migrating from DOS world would be familiar with it.  It
> is a little bit bigger than pico, but not much, about 60K on
> our RS6000 station (I'm not sure what the exact sizes are on
> linux, but I'd guess the relation is similar).

Pico has a two line on screen menu all the time, has single character 
commands, and a pico compatible editor is built into pine, a friendly 
easy to use, yet powerful mail user agent. I intend to bundle imapd and 
PC-pine, allowing client-server mail connections from a TCP/IP connected 
DOS PC. What do people think? I think that it should be a second optional 
package.

joe is a more powerful editor, but isn't intuitive. pico is based on 
microemacs, so the key strokes learnt are a stepping stone to emacs, if 
the user chooses to go that way.

Charlie Brady * (W) charlieb@tplrd.tpl.oz.au * (H) charlieb@budge.apana.org.au
"Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
  but no simpler"   Einstein, A  | Fax: (02) 413 6868 Pacing Systems    \/  


From debian-devel@pixar.com Sun Mar 27 09:05:19 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01838; Sun, 27 Mar 94 09:05:17 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkvNQ-0005pia; Sun, 27 Mar 94 05:59 PST
Date: Sun, 27 Mar 94 05:59 PST
Message-Id: <Pine.3.89.9403261042.A49-0100000@budge.apana.org.au>
Errors-To: bruce@pixar.com
Reply-To: charlieb@budge.apana.org.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: <charlieb@budge.apana.org.au>
To: debian-devel@pixar.com
Subject: Re: Berkeley (was UUCP)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

On Fri, 25 Mar 1994, Remy CARD wrote:

> 
> 	I have compiled sendmail 8.6.8 (the latest and greatest) under Linux.
> My version can use dbm maps but can also use the new db library from Berkeley.

Remy, is this Berkeley 4.4? The new db library with no size limits? Are we 
considering other new things from Berkeley, such as genuine vi with no 
line length limit, and fully eight bit clean? If we can legally use some 
of the new work from Berkeley, then I think we should. I think the source 
is freely avaliable and re-distributable, and it is certified uncontaminated.

Charlie Brady * (W) charlieb@tplrd.tpl.oz.au * (H) charlieb@budge.apana.org.au
"Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
  but no simpler"   Einstein, A  | Fax: (02) 413 6868 Pacing Systems    \/  


From debian-devel@pixar.com Sun Mar 27 10:50:39 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA01960; Sun, 27 Mar 94 10:50:32 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkx1H-0005o4a; Sun, 27 Mar 94 07:44 PST
Date: Sun, 27 Mar 94 07:44 PST
Message-Id: <199403271543.AA19733@prism.gatech.edu>
Errors-To: bruce@pixar.com
Reply-To: gt8134b@prism.gatech.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: gt8134b@prism.gatech.edu (Robert Sanders)
To: debian-devel@pixar.com
Subject: Re: Berkeley (was UUCP)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


charlieb@budge.apana.org.au writes:
> On Fri, 25 Mar 1994, Remy CARD wrote:
> 
> > My version can use dbm maps but can also use the new db library from Berkeley.
> 
> Remy, is this Berkeley 4.4? The new db library with no size limits? Are we 
> considering other new things from Berkeley, such as genuine vi with no 

Well, it's not really "genuine vi."  Much of the core was apparently lifted
from elvis.  From the man page:

     This manual page is the one provided with the nex and nvi versions of the
     vi text editors.  Nex and nvi are intended as bug-for-bug compatible re-
     placements for the original Fourth Berkeley Software Distribution (4BSD)
     ex and vi programs.
[...]
HISTORY
     The nex/nvi replacements for ex/vi first appeared in 4.4BSD.

> line length limit, and fully eight bit clean? If we can legally use some 
> of the new work from Berkeley, then I think we should. I think the source 
> is freely avaliable and re-distributable, and it is certified uncontaminated.
 
Look at this:

$ ls -l `which nvi` `which elvis`
-rwxr-xr-t   1 root     bin         99332 Jan 14 08:18 /usr/bin/elvis
-rwxr-xr-x   2 root     bin        300036 Mar  4 16:33 /usr/bin/nvi

nvi's bloat is partly caused by the inclusion of a new BSD curses
and the db library.  I tried linking nvi against ncurses and it was
SLOW.  nvi uses more capability than is available in the current Linux
version of BSD curses (i.e. the one in the shared library).  So, it's
either large with BSD4.4 curses or large and slow with ncurses.  If
the BSD4.4 curses can be binary compatible with the older BSD curses,
then it might be nice to get them into the libc shared library.

As for the new db, well, I don't think it's even source compatible
with ndbm/gdbm.  It may be the best thing since sliced bread, but
gdbm is what's in the shared library, and it works pretty well
for me.  Now, that's not an argument against including libdb.a
in Debian, just that making it the system db library probably
isn't a good idea.

One good thing about nvi is that it comes with comprehensive documents
about vi.  Not just a reference card, of which there are untold numbers
floating around, but real honest-to-god manuals.  These are the preformatted
versions (they're ms or me troff source):

-rw-r--r--   1 root     root        82990 Mar  8 13:12 ex.rm.txt
-rw-r--r--   1 root     root        20344 Mar  8 13:12 ex.summary.txt
-rw-r--r--   1 root     root       140173 Mar  8 13:11 vi.intro.txt
-rw-r--r--   1 root     root        59579 Mar  8 13:11 vi.rm.txt
-rw-r--r--   1 root     root        13035 Mar  8 13:11 vi.summary.txt

Of course, I don't care one way or the other which vi Debian uses,
because I'm an Emacs fanatic.


From debian-devel@pixar.com Sun Mar 27 11:01:48 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02022; Sun, 27 Mar 94 11:01:46 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkxC9-0005oJa; Sun, 27 Mar 94 07:56 PST
Date: Sun, 27 Mar 94 07:56 PST
Message-Id: <199403271554.AA20946@prism.gatech.edu>
Errors-To: bruce@pixar.com
Reply-To: gt8134b@prism.gatech.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: gt8134b@prism.gatech.edu (Robert Sanders)
To: debian-devel@pixar.com
Subject: Re: The X11 package for Debian (long)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Helmut Geyer writes:
> 
> Leading # means that this package should be there, but is IMHO not 
> placed rightly in the X11 packages. Mostly a more proper location
> is pointed out.
> Leading R means that I think of this part as required to run X11.
 
>      - windowmanagers (wm):
> R           fvwm (this should be the standard wm), including pixmaps and

Well, okay.  Everyone seems to love that damn thing, but I find it distasteful.
I can't tell if it's aiming at the look-and-feel of Windows or Motif.  I
also was not overly impressed by the memory savings, but there were
definitely some differences between the memory usage of fvwm and that
of ctwm.

> ?       Is there need for other wm choices (besides olvwm that comes with the
> ?       xview contrib package)? I can provide ctwm, piewm and gwm as well,

I think ctwm can satisfy the *twm needs of most everybody.  It also seems
to be the only *twm that's being actively developed.

> R        libXpm (at present version 3.3, haven't tried 3.4 yet) including 
>                 the pixmap editor pixmap 2.4.

ctwm can use this as well.

>          libgr (at present only needed for xv, but I think it should be 

Well, the svgalib graphics viewers zgv, spic, and seejpeg can all link
against this.  It's a substantial savings in disk space, if you don't
keep the .a files around as well.

>       xdvik, bibview, xtexcad, transfig 

What is xdvik?  Is that a type of xdvi, or is that an enhancement?  
Is xtexcad stable now?  The last time I used it (a long time ago) it
segfaulted whenever I sneezed.  

From debian-devel@pixar.com Sun Mar 27 14:36:29 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02633; Sun, 27 Mar 94 14:36:27 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pl0Xt-0006ARa; Sun, 27 Mar 94 11:30 PST
Date: Sun, 27 Mar 94 11:30 PST
Message-Id: <m0pl0Wo-0005uPC@mongo.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: pat@it.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: pat@it.com.au (Pat Mackinlay)
To: debian-devel@pixar.com
Subject: Another minor Debian 0.91 buglet
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

<Moderator's note: I let one slip by this morning. Sorry. - Bruce>

[ I seem to have a knack of finding insignificant non-bugs in software -
someone please tell me to shut up if the reports are not wanted <grin> ]

Dan Quinlan's sman is formatting and compressing manpages perfectly
correctly, but the resultant compressed formatted file is being given
a ".z" extension, rather than the ".gz" being used by gzip these days.

Told you it was minor <grin>.

-- 
pat -- pat@it.com.au


From debian-devel@pixar.com Sun Mar 27 16:14:37 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02910; Sun, 27 Mar 94 16:14:34 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pl24r-0005oDa; Sun, 27 Mar 94 13:09 PST
Date: Sun, 27 Mar 94 13:09 PST
Message-Id: <m0pl24M-00067PC@mongo.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: pat@it.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: pat@it.com.au (Pat Mackinlay)
To: debian-devel@pixar.com
Subject: Correction...
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Upon closer inspection, it's not Dan Q's sman at all - it's the older
man package. The problem remains, however...

-- 
pat -- pat@it.com.au


From debian-devel@pixar.com Sun Mar 27 16:59:21 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA03072; Sun, 27 Mar 94 16:59:17 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pl2m7-0009pya; Sun, 27 Mar 94 13:53 PST
Date: Sun, 27 Mar 94 13:53 PST
Message-Id: <m0pl2l2-0005WFC@mongo.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: quinlan@spectrum.cs.bucknell.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan)
To: debian-devel@pixar.com
Subject: Re: Another minor Debian 0.91 buglet
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Pat Mackinlay <pat@it.com.au> writes:

> Dan Quinlan's sman is formatting and compressing manpages perfectly
> correctly, but the resultant compressed formatted file is being
> given a ".z" extension, rather than the ".gz" being used by gzip
> these days.

Just a small note: it isn't my sman.

sman was written by Darren Senn who I have been unable to contact.
I've only fixed some bugs and made some small improvements.  I hope to
improve upon it quite a bit, but unfortunately I haven't been able to
spend any significant amount of time on it.

If anyone wants to help improve upon it, I will be quite happy to
incorporate (good) changes.  The source will be a part of the Debian
source distribution.  It is copyrighted by Darren Senn, but is freely
redistributable.

sman does use ".gz" and comes with `catman', a C-based replacement for
`makewhatis' that works rather well (and quickly too).

Dan

--
Daniel Quinlan  <quinlan@spectrum.cs.bucknell.edu>


From debian-devel@pixar.com Sun Mar 27 17:54:42 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA03257; Sun, 27 Mar 94 17:54:38 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pl3dh-0005qpa; Sun, 27 Mar 94 14:49 PST
Date: Sun, 27 Mar 94 14:49 PST
Message-Id: <m0pl3cd-0005hEC@mongo.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Stephen White's proposal involving a `private' group
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

(I'll not repeat things that Matthew Birkholz has said - I agree with
 him here and also regarding the question of revision control.)

Stephen White's scheme has a serious disadvantage compared to most
other arrangments: it becomes very hard for users to control access to
their files effectively.

This is because they can't chgrp any files with different ownerships
back to the state they were in when they were created in their home
directory (because they're not a member of the group).  The only way
to do it is to make a new copy of the file and delete the old one.
This would be quite tedious in the case of directory trees and even
more so in the case of files with multiple hard links.

If and when someone writes a set of programs to allow user-maintained
groups this problem will become even more serious, as users will need
to use the chgrp command on a regular basis to grant and deny access.

It should also be noted that Stephen White's proposal won't work
unless the home directories filesystem and /tmp are both mounted with
BSD semantics.

This is because the setgid bit doesn't get propagated to
subdirectories you create unless you're a member of the group in
question.

Ian.


From debian-devel@pixar.com Sun Mar 27 17:56:41 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA03301; Sun, 27 Mar 94 17:56:35 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pl3fa-0005rIa; Sun, 27 Mar 94 14:51 PST
Date: Sun, 27 Mar 94 14:51 PST
Message-Id: <m0pl3dX-0009kvC@mongo.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: new adduser - please test
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian Murdock writes:
> Appended are the files /usr/sbin/adduser and /etc/default/adduser from
> Debian 0.92.  I have just updated adduser in several ways, including
> support for the project group idea.  I have not had much time to test
> it (I'm working the 11-8 weekend shift now... :/).  I need to know how
> well it works, so please test it thoroughly and let me know how it can
> be improved.  Feel free to improve it yourself and mail me your
> changes.

I've tested it and it appears to work.  However, I think a few changes
in order.  Enclosed below is a unidiff to adduser and a new
adduser.conf file.

Ian.


Changes:

* I've renamed the METHOD variable, with values "project" and
"default", to a USERGROUPS variable, with values "yes" and "no".

* I've made user private groups the default.  See my earlier message
for why this is a Good Thing.  Please can this be the default, it's
just going to cause problems for people if it isn't, especially now
that we have a `staff'-writeable /usr/local (people will be added to
the staff group but won't have a group created for them and their
umask changed, or worse have their umask changed without getting their
own group ...).

* According to the latest FSSTND practice, /etc/default is a Bad
Thing.  I've therefore changed things to use /etc/adduser.conf
instead.

* I've added `set -e' to the top of adduser.

* There is no need to create the user's mailbox - the mail transport
software does that.  In fact, some mailreaders (Emacs, for example)
delete empty mailboxes when they have taken the mail out of them.

* I've fixed the code that massages the dotfiles for the umask change
to work with other umasks than 022.  Any umask 0nn will be changed to
00n; anything else will be left unchanged.  I've also changed it to
use a loop instead of three copies of the same code.  I'm not sure why
bashrc is mentioned there - it shouldn't be necessary, but I've left
it in anyway.

* The /etc/adduser.conf file's comments are more informative.


Remaining bugs/misfeatures:

* My Debian 0.91 system doesn't appear to have chfn.

* The passwd program is too fascist for some people's tastes, I'm
sure, and is impossible to interrupt !

* The /etc/passwd file locking has a race condition.  Unfortunately
this requires the link command to fix properly, and Linux doesn't
appear to have link.


====== patch to adduser:

--- adduser.orig	Sun Mar 27 20:28:53 1994
+++ adduser	Sun Mar 27 21:12:25 1994
@@ -19,6 +19,8 @@
 #    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 #
 
+set -e
+
 # Everything happens too fast, so don't let the user interrupt.  We
 # certainly don't want a half-done job.
 trap "" 1 2 3 15
@@ -37,16 +39,16 @@
 				# Is there a ``standard'' method of locking the
 				# group file?
 
-DEFAULTS="/etc/default/adduser"
+DEFAULTS="/etc/adduser.conf"
 
-# This is a bit tricky.  If method is "default" and there are no users in the
+# This is a bit tricky.  If USERGROUPS is "yes" and there are no users in the
 # default group, then add the user to the group in $GROUP without a leading
 # comma.  If there are, then add the user to the group in $GROUP preceded by
 # a comma.  If method is "project", then simply create the new group and add
 # the user to it.
 add_to_group()
 {
-	if [ $METHOD = "default" ]; then
+	if [ $USERGROUPS = "no" ]; then
 	 # First of all, determine the name of the group.
 	 GROUP_NUM=$1
 	 GROUP_NAME=`grep "::$GROUP_NUM:" $GROUP | cut -f 1 -d ":"`
@@ -75,8 +77,7 @@
 	DSHELL="/bin/bash"
 	DHOME="/home"
 	SKEL="/etc/skel"
-	SPOOL="/var/spool/mail"
-	METHOD="default"
+	USERGROUPS="yes"
 	FIRST_UID=1000
 	USERS_GID=1000
 }
@@ -101,6 +102,8 @@
 
 # Okay, we can.
 cp $PASSWD $PLOCK
+# Damn! We don't have link(1) (or is it link(8)?), so we'll
+# have to live with the race condition - iwj
 
 # And now the program begins.
 if [ -f $DEFAULTS ]; then
@@ -115,15 +118,13 @@
 if [ $NUID -lt $FIRST_UID ]; then
 	NUID=$FIRST_UID
 fi
-if [ $METHOD = "default" ]; then
+if [ $USERGROUPS = "no" ]; then
 	NGID=$USERS_GID
+elif [ $USERGROUPS = "yes" ]; then
+	NGID=$NUID
 else
-	if [ $METHOD = "project" ]; then
-		NGID=$NUID
-	else
-		echo -e "\n$0: unknown method \`$METHOD'."
-		rm -f $PLOCK ; exit 1
-	fi
+	echo -e "\n$0: USERGROUPS should be \`yes' or \`no'; \`$METHOD' is unknown."
+	rm -f $PLOCK ; exit 1
 fi
 echo "done.  Using UID $NUID and GID $NGID."
 
@@ -150,20 +151,22 @@
 	echo -e "\n*** $DHOME/$LOGIN already exists!  Not copying files from $SKEL. ***"
 else
 	mkdir $DHOME/$LOGIN
-	if [ $METHOD = "project" ]; then
-		chmod 775 $DHOME/$LOGIN ; chown $NUID.$NGID $DHOME/$LOGIN
+	if [ "$USERGROUPS" = "yes" ]; then
+		chmod 2775 $DHOME/$LOGIN ; chown $NUID.$NGID $DHOME/$LOGIN
 	fi
-	cp -i $SKEL/.[a-z]* $SKEL/* $DHOME/$LOGIN >/dev/null 2>&1
-	if [ $METHOD = "project" ]; then
-		test -f $DHOME/$LOGIN/.bashrc && \
-		 ( sed "s/umask 022/umask 002/" $DHOME/$LOGIN/.bashrc > \
-		   /tmp/.bashrc ; mv /tmp/.bashrc $DHOME/$LOGIN/.bashrc )
-		test -f $DHOME/$LOGIN/.profile && \
-		 ( sed "s/umask 022/umask 002/" $DHOME/$LOGIN/.profile > \
-		   /tmp/.profile ; mv /tmp/.profile $DHOME/$LOGIN/.profile )
-		test -f $DHOME/$LOGIN/.login && \
-		 ( sed "s/umask 022/umask 002/" $DHOME/$LOGIN/.login > \
-		   /tmp/.login ; mv /tmp/.login $DHOME/$LOGIN/.login )
+	cp -i $SKEL/.[a-z]* $SKEL/* $DHOME/$LOGIN >/dev/null 2>&1 || true
+	if [ "$USERGROUPS" = "yes" ]; then
+		for dotfile in .bashrc .profile .login
+		do
+			if [ -f $DHOME/$LOGIN/$dotfile ]
+			then
+				sed 's/umask 0\([267]\)\1/umask 00\1/' \
+					$DHOME/$LOGIN/$dotfile \
+					> $DHOME/$LOGIN/$dotfile.new
+				mv $DHOME/$LOGIN/$dotfile.new \
+				   $DHOME/$LOGIN/$dotfile
+			fi
+		done
 	fi
 	# Probably will never happen, but just in case... we don't want all
 	# files on the system to be `chown'ed to $NUID.$NGID!
@@ -173,10 +176,6 @@
 	echo "done."
 fi
 
-echo -n "Creating mailbox: $SPOOL/$LOGIN..."
-touch $SPOOL/$LOGIN ; chmod 660 $SPOOL/$LOGIN ; chown $NUID.mail $SPOOL/$LOGIN
-echo "done."
-
 passwd $LOGIN
 chfn $LOGIN
 

===== new /etc/adduser.conf

# The DSHELL variable specifies the default login shell on your system.
DSHELL="/bin/bash"

# The DHOME variable specifies the directory containing users' home
# directories.
DHOME="/home"

# The SKEL variable specifies the directory containing `skeletal' user
# files; in other words, files such as a sample .profile that will be
# copied to the new user's home directory when it is created.
SKEL="/etc/skel"

# FIRST_UID should be the first UID for users on your system.  UIDs
# (and GIDs) below FIRST_UID are reserved for administrative and
# system accounts.
FIRST_UID=1000

# The USERGROUPS variable can be either "yes" or "no".
# If "yes" each created user will be given their own group to use as a
# default, and their setup will arrange to have them create files
# group-writeable by default, thus allowing them to effectively use
# group-writeable filespace areas (such as /usr/local).
# If "no" each created user will be placed in the group whose gid is
# USERS_GID (see below), and they will create files not world writeable
# by default.
USERGROUPS="yes"

# If USERGROUPS is "no", then USERS_GID should be the GID of the group
# `users' (or the equivilant group) on your system.
USERS_GID=100

===== the end - iwj


From debian-devel@pixar.com Sun Mar 27 20:33:28 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA04147; Sun, 27 Mar 94 20:33:26 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pl67M-0009kva; Sun, 27 Mar 94 17:27 PST
Date: Sun, 27 Mar 94 17:27 PST
Message-Id: <m0pl65q-0005YzC@mongo.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Documentation of the private groups proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

I'm not sure whether the moderation policy is to kill the flamewar by
prohibiting discussion of this issue.  In case it isn't and this
message is approved I shall try to keep myself away from such
inflammatory language and style as I can probably be considered to
have used.

< Thanks. As long as everyone (not just Ian) keeps a moderate tone and the >
< topic is related to Debian, I don't see a problem with the continuation  >
< of this issue. So far, nobody's asked me to squelch this subject, and it >
< would take a lot of complaints for me to do so. - Bruce (Moderator)      >

Bill Mitchell makes some interesting points about documentation.

I agree that documentation is required; a Debian administrators'
supplement would be a very useful (nay, required) document anyway.

I would be more than happy to write or help write such a document.

Also, as I said earlier, several manpages need to be brought up to
speed on the setgid option.  When I have a spare moment I'll submit
some improved ones to Rik Faith.

I think that perhaps Bill is misinterpreting my attitude, when he says:
> I know, it's easy to pass this off with a "that's just a
> documentation issue", and presume that it'll be dealt with later.

I'm not the kind of person to dismiss something because it's `just a
documentation issue' - in fact, most of my contributions to the Linux
community have been documentation of one form or another.

What I suppose I was really trying to say was not `oh, that's just
documentation and not important' but more `yes, it needs to be
documented, but don't worry, I'll/we'll take care of it'.

I agree strongly with Bill when he writes:
> Before debian goes into general non-beta release, the documentation needs
> to be better than half-assed.

However, there are a couple of things in his message that I want to
take issue with:
>  ...  We need to be documenting it as we are implementing it,
> not thinking about documenting it; and we should not be releasing it with 
> the special issues in it unless it is accompanied by documentation of the 
> special issues.

That depends on what you mean by `release'.  It is very hard for an
`outsider' to document something that doesn't exist, and it is IMO a
bad idea to burden those putting together code by saying `thou shalt
produce documentation for everything'.  Therefore the documentation
has to be written after the fact.  This also tends to produce
documentation that agrees much more closely with the implementation.

The right time to be writing documentation is IMO in the period where
the beta testers are finding bugs, after the major design issues have
settled down.

At the moment we don't appear even to have a set of installation
instructions for example - Debian is lacking the documentation that
has to go with a publicly released system.  This is a perfectly
reasonable situation at the moment, but will obviously need work to
correct.

> Any nontraditional umask usage needs to be prominently documented.

Experience I've had on systems which have such a `nontraditional'
umask is that there are no problems even in the absence of any
documentation at all about that arrangement.

Here a paragraph in the FM for adduser and some more detail in the
permissions section in the Debian administrators' supplement will be
enough, I think.

In practice, users neither know nor care, provided that `it works'.

> And if we're going to start UIDs at 1000 (or whatever) we need to explain
> why we did that, explain it well, and and explain it prominently.

Obviously the starting point for UIDs will be documented in adduser(8)
and the administrators' supplement.  However, this doesn't strike me
as a very major issue.

> I'm getting the feeling that it's likely debian will implement something
> in this area in 0.92.  If so, debian 0.92 should include at least half-assed
> documentation of what's been done, of the effects it'll have on sysadmin, and
> of the effects it'll have on Joe User (who won't care) and Jane User (who
> will find it useful once she understands it and understands how to take
> advantage of it).

Again, I think it is a mistake to try to document something that is in
such a state of flux.  If 0.92 is going to be a stable base then
*after* it has been released we can document it.  It's not reasonable
to ask Ian Murdock &co to write all the documentation - they've
already got too much on their plates ...

Remember that Debian is still in beta test - to my mind that means
that only people who don't need the documentation that badly should be
using it.

Ian.
------- End of forwarded message -------


From debian-devel@pixar.com Mon Mar 28 11:51:03 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA08038; Mon, 28 Mar 94 11:51:00 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plKRK-0006yca; Mon, 28 Mar 94 08:45 PST
Date: Mon, 28 Mar 94 08:45 PST
Message-Id: <199403281645.IAA10013@beagle.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: bruce@beagle.pixar.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: bruce@beagle.pixar.com
To: debian-devel@pixar.com
Subject: Moderation OFF
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Moderation of debian-devel and debian-user is now being turned OFF.
Please, everyone, try to moderate yourselves - when I have to turn
moderation ON, it takes time away from my other projects.

Tidbits from Bruce's guide to non-provocational language (Soapbox on):

"That's not true" and "This is false" are sometimes better said as: "That
turns out not to be the case".

"That's a dishonest debating tactic" might be better said as "Are you sure
that's a valid debating tactic?".

You get the picture. Try to get your message across without implying that
the other party is an unsavory character, even if you really think they are.

For those who may think little of the mental faculties of their opposition
in a debate: When you are in a fight with an idiot it's hard for anyone
else to tell which person the idiot is.

Soapbox off.

	Thanks

	Bruce

From debian-devel@pixar.com Mon Mar 28 11:26:37 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA07823; Mon, 28 Mar 94 11:26:35 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plK3g-0006iia; Mon, 28 Mar 94 08:21 PST
Date: Mon, 28 Mar 94 08:21 PST
Message-Id: <m0plK14-0005qOC@mongo.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: mitchell@mdd.comm.mot.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
To: debian-devel@pixar.com
Subject: Re: Berkeley (was UUCP)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Regarding vi clones, gt8134b@prism.gatech.edu said:

> [...]
> One good thing about nvi is that it comes with comprehensive documents
> about vi.  Not just a reference card, of which there are untold numbers
> floating around, but real honest-to-god manuals.  These are the preformatted
> versions (they're ms or me troff source):
> 
> -rw-r--r--   1 root     root        82990 Mar  8 13:12 ex.rm.txt
> -rw-r--r--   1 root     root        20344 Mar  8 13:12 ex.summary.txt
> -rw-r--r--   1 root     root       140173 Mar  8 13:11 vi.intro.txt
> -rw-r--r--   1 root     root        59579 Mar  8 13:11 vi.rm.txt
> -rw-r--r--   1 root     root        13035 Mar  8 13:11 vi.summary.txt
> 
> Of course, I don't care one way or the other which vi Debian uses,
> because I'm an Emacs fanatic.

The Elvis distribution comes with a (IMHO) very good manual in ms troff,
covering vi usage from scratch as well as elvis vi extensions.  It's not a 
tutorial, but it is a good reference manual.  I've included the manual
in the elvis 1.8pl2 package for debian linux which I believe will be 
in the debian 0.92beta release.


From debian-devel@pixar.com Mon Mar 28 11:24:39 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA07798; Mon, 28 Mar 94 11:24:35 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plK1k-0006Eha; Mon, 28 Mar 94 08:19 PST
Date: Mon, 28 Mar 94 08:19 PST
Message-Id: <m0plK0m-00064iC@mongo.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: stephen.white@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: stephen.white@adam.com.au
To: debian-devel@pixar.com
Subject: STEPHEN WHITE'S PROPOS
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Ian Jackson writes:

 > Stephen White's scheme has a serious disadvantage compared to most
 > other arrangments: it becomes very hard for users to control access 
 > to their files effectively.
 > 
 > This is because they can't chgrp any files with different ownerships
 > back to the state they were in when they were created in their home
 > directory (because they're not a member of the group).  The only way
 > to do it is to make a new copy of the file and delete the old one.
 > This would be quite tedious in the case of directory trees and even
 > more so in the case of files with multiple hard links.

When users start manually manipulating permissions (like above), then the
automagical aspects of private groups do tend to become less useful. I don't
agree that the above problem is a serious disadvantage.

The above only applies to the situation where a user has made files in their
own directory available with the chgrp command, and then wishes to hide them
again. In this circumstance, the user can do "chmod g-rwx file" to achieve the
same effect that a "chgrp private file" would achieve (were it possible).

 > It should also be noted that Stephen White's proposal won't work
 > unless the home directories filesystem and /tmp are both mounted 
 > with BSD semantics.

Only the home directories filesystem needs to be mounted with BSD semantics.
However, your main point is still correct, and I hadn't spotted this.

My proposal was worked out with the assumption that things were mounted with
BSD semantics. I did this because Remy (author of the ext2 file system) is
seeing if he is allowed to make the Linux kernel default to BSD mounting.

If Linus chooses to retain SysV defaults, then that marks the end of this
thread. If BSD mounting becomes the default, then the setgid debate needs to be
reviewed from the other direction ("Should we retain non-standard SysV
semantics with a 'nogrpid' in /etc/fstab?").

So unless BSD mounting becomes the default, I suggest that my proposal be
shelved. I would still welcome comments from the people who opposed multiple
private groups. I would like to know if my proposal suited their needs better.


Steve.



From debian-devel@pixar.com Mon Mar 28 11:24:07 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA07767; Mon, 28 Mar 94 11:24:02 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plK1D-0005pIa; Mon, 28 Mar 94 08:18 PST
Date: Mon, 28 Mar 94 08:18 PST
Message-Id: <m0plK00-00064iC@mongo.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: matth@ucc.su.oz.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Matthew Hannigan <matth@ucc.su.oz.au>
To: debian-devel@pixar.com
Subject: Re: Stephen White's proposal involving a `private' group 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Stephen White writes:
>> [ private group to which no one belongs but which is the group
>> owner of their home directories ]

As Matt Birkholz writes, interesting idea.

Ian Jackson writes
> [ can't chgrp files to private in case they're not already ]
> [ new directories do not inherit setgid ]

Yes, I came up the same idea simultaneously and was
investigating it on the Suns here at work a few days ago and
came across these problems.  Actually, though I don't notice the
second.  I thought it wouldn't inherit either the setgid bit
_or_ the group, and I was so surprised when it got the group
that I didn't notice the lack of setgid.

Warning : unix/linux speculation/wishlist mode follows which
doesn't necessarily have to do with debian follows:

1.  What would be nice is a group which is a true "nullgroup" --
everyone can change their files to nullgroup , but no one gets
any permission through this -- group permissions are ignored. In
effect the file would effectively have no group.  I thought the
current "nogroup" (gid 65534) on Suns would do this, but no.

2.  Another nice thing would be to have files which inherit
a umask from the directory as well as the gid: if a dir
was 2775, then files created would be 664 or 775. (unless
explicitly changed) i(this might require a magic umask as well
e.g. -1)

These would both require kernel changes.

wishlist mode OFF.

Serious now :-)  What this proposal would have saved is 
the large group file.  But I don't think is a problem.

As for the other issues -- NFS and version control --
I haven't found any problem in the current proposal
with respect to those, either.

--
	-Matt Hannigan


From debian-devel@pixar.com Mon Mar 28 12:14:09 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA08245; Mon, 28 Mar 94 12:14:06 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plKnf-0006iya; Mon, 28 Mar 94 09:08 PST
Date: Mon, 28 Mar 94 09:08 PST
Message-Id: <m0plKmr-000674C@mongo.pixar.com>
Errors-To: bruce@pixar.com
Reply-To: bruce@pixar.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: bruce@pixar.com (Bruce Perens)
To: debian-devel@pixar.com
Subject: 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

>From pixar.com!debian-devel Mon Mar 28 08:36:02 1994
Return-Path: <debian-devel@pixar.com>
Received: from pixar.com by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plKIE-0006AIa; Mon, 28 Mar 94 08:36 PST
Received: from mongo.pixar.com by pixar.com with SMTP id AA13736
  (5.65c/IDA-1.4.4 for <bruce@pixar.com>); Mon, 28 Mar 1994 08:36:06 -0800
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plKI6-0006AAa; Mon, 28 Mar 94 08:35 PST
Date: Mon, 28 Mar 94 08:35 PST
Message-Id: <9403281634.AA25684@bb29c.mdd.comm.mot.com>
Errors-To: bruce@pixar.com
Reply-To: mitchell@mdd.comm.mot.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
To: debian-devel@pixar.com
Subject: Re: Documentation of the private groups proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: R

This message was submitted by mitchell@mdd.comm.mot.com (Bill Mitchell) to list
debian-devel@pixar.com. If you forward it back to the list, it will be
distributed without the paragraphs above the dashed line. You may edit the
Subject: line and the text of the message before forwarding it back.

If you edit the messages you receive into a digest, you will need to remove
these paragraphs and the dashed line before mailing the result to the list.
Finally, if you need more information from the author of this message, you
should be able to do so by simply replying to this note.

----------------------- Message requiring your approval ----------------------
Sender: mitchell@mdd.comm.mot.com (Bill Mitchell)
Subject: Re: Documentation of the private groups proposal

iwj10@cus.cam.ac.uk (Ian Jackson) said, regarding my remarks re documentation:

>[...]
> I think that perhaps Bill is misinterpreting my attitude, when he says:
> > I know, it's easy to pass this off with a "that's just a
> > documentation issue", and presume that it'll be dealt with later.

I wasn't directing my remarks specifically at anything Ian had said.  I
characterized my remarks as drumbeating about documentation, and that's
how they were intended.  I've been watching the greate debate on this,
and seen the forces for change gathering momentum.  After everyone has
spent so much time and effort arguing their respective points, I just
thought it needed pointing up that it would be inappropriate for the
victorious faction to breathe a sigh of releif and go on to other things
once the issue is decided.  Programming is like defecating in that the
job is not completed until the paperwork has been properly done. <<<You
would send this just as I am about to turn off moderation! - Bruce>>> In
this case, the paperwork would seem to involve several documentation issues.

Ian goes on to say
>[...]
> I agree strongly with Bill when he writes:
> > Before debian goes into general non-beta release, the documentation needs
> > to be better than half-assed.
> 
> However, there are a couple of things in his message that I want to
> take issue with:
> >  ...  We need to be documenting it as we are implementing it,
> > not thinking about documenting it; and we should not be releasing it with 
> > the special issues in it unless it is accompanied by documentation of the 
> > special issues.
> 
> That depends on what you mean by `release'.  It is very hard for an
> `outsider' to document something that doesn't exist, and it is IMO a
> bad idea to burden those putting together code by saying `thou shalt
> produce documentation for everything'.  Therefore the documentation
> has to be written after the fact.  This also tends to produce
> documentation that agrees much more closely with the implementation.
>
> The right time to be writing documentation is IMO in the period where
> the beta testers are finding bugs, after the major design issues have
> settled down.
>[...]
> Remember that Debian is still in beta test - to my mind that means
> that only people who don't need the documentation that badly should be
> using it.

I think that this particular case requires some documentation in the
debian release in which shows up.  User-notes stuff in a text file
should probably do it for a beta release, provided that the text file
is made conspicuous somehow (perhaps a default motd pointing users to
a README file about the release, and a prominent mention this file in
the release README file, and a pointer to the file for more info).

I recall much argument here about what these changes do and do not do,
what effect they do and do not have, what protections they do and do
not offer, how they are or are not intrusive on unintrested users, and
what an interested user does and does not need to do in order to take
advangage of these changes.  I doubt that even those reading all the
debian lists will remember all of that -- much less users who will get a
copy of debian 0.92beta without having seen all the discussions in all
the lists.


From debian-devel@pixar.com Mon Mar 28 14:30:14 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA09778; Mon, 28 Mar 94 14:29:59 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plMh2-0005rca; Mon, 28 Mar 94 11:09 PST
Date: Mon, 28 Mar 94 11:09 PST
Message-Id: <10299.9403281908@cent1.lancs.ac.uk>
Errors-To: bruce@pixar.com
Reply-To: pyd001@cent1.lancs.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: "Zack Evans" <pyd001@cent1.lancs.ac.uk>
To: debian-devel@pixar.com
Subject: Re: The X11 package for Debian (long)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

> Leading # means that this package should be there, but is IMHO not 
> placed rightly in the X11 packages. Mostly a more proper location
> is pointed out.
> Leading R means that I think of this part as required to run X11.
> 
> - XFree86 category:
>       complete XFree86 2.1 distribution (I would like to have it like 
>       this, nothing added, nothing left out) without servers and LinkKit.

Mmmm, but a lot of it is cruft; personally I'd repackage the useless things in
/usr/X386/bin in a different .deb to the rest of the default /usr/X386/bin.
By 'useless' I mean things like xgas, puzzle, maze...

xbin.deb and xdemo.deb perhaps?

> ?       Is there need for other wm choices (besides olvwm that comes with the
> ?       xview contrib package)? I can provide ctwm, piewm and gwm as well,
> ?       but do not like them as well.

Put twm in because it's the 'standard'. Include vtwm as a lot of people use
this or tvtwm, and the two are so similar that users of the latter can switch
to the former easily. (vwtm seems to be better maintained, and has a real root
window).

> - X11 developer category :
> ?     Do we want to keep the shared and the static/stub libraries in one 
> ?     package or do we want to split them up and put the static/stubs into 
> ?     this category? I want to be able to compile anything I can run on the 
> ?     system by myself without installing a second package, but it takes
> ?     a lot of disk space to have the static/stubs and headers around.

I got bitten by this today. I had moved all the static libs off the hard disk
on the theory I never linked anything statically so there was little point.
Then when I tried to debug an X program I am writing, I suddenly realised -g
implies -static :)

Since 'developer' kind of implies you might want -g, I'd say yes include the
static libs.

> - tinyX (requires XFree86 & Xservers) category:
>      package for X11 on systems with small memory.

Surely it would be better to package the above in such a way that you can
essentially recreate TinyX by what you choose to download? (Hence my comments
about the junk in /usr/X386/bin

>      - xv 3.00a patched for gzip (this is Shareware and should therefore
>        perhaps go into the contrib package, though it is very useful).
>        inluded some demo pictures (logos in different formats, Linus GIFs)
>        (requires gs with pbmraw support)

You could always ask John Bradley for consent to make sure... from reading the
licensing file that might be a good idea. If not you'll have to include xv 2.21
instead.

> - X11 connectivity:

xmosaic static binaries?

>      - aXe 6.1
> ?        are there other editors needed? I use emacs only, so I couldn't 
> ?        know...

Xcoral is a bloody good code editor... I intend to compile it anyway so I can
supply the bins if you like (-m386 though :P)

Zack
-- 
Zack Evans        pyc081@cent1.lancs.ac.uk or zevans@nyx.cs.du.edu (Internet)
                  pyc081@uk.ac.lancs.cent1                         (JANET)

Watch yer bass bins lads, I'm tellin' yer...


From debian-devel@pixar.com Mon Mar 28 14:04:15 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA09485; Mon, 28 Mar 94 14:04:07 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plMW9-0006Bxa; Mon, 28 Mar 94 10:58 PST
Date: Mon, 28 Mar 94 10:58 PST
Message-Id: <199403281857.AA19835@masi.ibp.fr>
Errors-To: bruce@pixar.com
Reply-To: Remy.Card@masi.ibp.fr
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Remy.Card@masi.ibp.fr (Remy CARD)
To: debian-devel@pixar.com
Subject: Re: Stephen White's proposal involving a `private' group
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


	Hi,

	I just want to state a technical point here, no flame intended :-)

Ian Jackson writes:
> 
> It should also be noted that Stephen White's proposal won't work
> unless the home directories filesystem and /tmp are both mounted with
> BSD semantics.
> 
> This is because the setgid bit doesn't get propagated to
> subdirectories you create unless you're a member of the group in
> question.

	This is untrue.  If you look at the ext2fs code (in file
fs/ext2/ialloc.c), at line 479:

        if (test_opt (sb, GRPID))
		/*
		 * Using BSD semantics, gid is inherited by the new inode
		 */
		inode->i_gid = dir->i_gid;
        else
		/*
		 * Using System V semantics
		 */
		if (dir->i_mode & S_ISGID) {
			/*
			 * setgid directory, gid is inherited
			 */
			inode->i_gid = dir->i_gid;
			if (S_ISDIR(mode))
				/*
				 * setgid bit is inherited on subdirectories
				 */
				mode |= S_ISGID;
		} else
			/*
			 * Non setgid directory, use the creator gid
			 */
			inode->i_gid = current->egid;

	I have slightly edited the code (to add comments).  As you can see in
the code, the gid of a setgid directory is inherited by its subdirectories
even if the creator does not belong to the group.  This works the same way in
other filesystems.

> 
> Ian.
> 

		Remy

From debian-devel@pixar.com Sun Mar 27 11:01:48 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA02022; Sun, 27 Mar 94 11:01:46 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pkxC9-0005oJa; Sun, 27 Mar 94 07:56 PST
Date: Sun, 27 Mar 94 07:56 PST
Message-Id: <199403271554.AA20946@prism.gatech.edu>
Errors-To: bruce@pixar.com
Reply-To: gt8134b@prism.gatech.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: gt8134b@prism.gatech.edu (Robert Sanders)
To: debian-devel@pixar.com
Subject: Re: The X11 package for Debian (long)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Helmut Geyer writes:
> 
> Leading # means that this package should be there, but is IMHO not 
> placed rightly in the X11 packages. Mostly a more proper location
> is pointed out.
> Leading R means that I think of this part as required to run X11.
 
>      - windowmanagers (wm):
> R           fvwm (this should be the standard wm), including pixmaps and

Well, okay.  Everyone seems to love that damn thing, but I find it distasteful.
I can't tell if it's aiming at the look-and-feel of Windows or Motif.  I
also was not overly impressed by the memory savings, but there were
definitely some differences between the memory usage of fvwm and that
of ctwm.

> ?       Is there need for other wm choices (besides olvwm that comes with the
> ?       xview contrib package)? I can provide ctwm, piewm and gwm as well,

I think ctwm can satisfy the *twm needs of most everybody.  It also seems
to be the only *twm that's being actively developed.

> R        libXpm (at present version 3.3, haven't tried 3.4 yet) including 
>                 the pixmap editor pixmap 2.4.

ctwm can use this as well.

>          libgr (at present only needed for xv, but I think it should be 

Well, the svgalib graphics viewers zgv, spic, and seejpeg can all link
against this.  It's a substantial savings in disk space, if you don't
keep the .a files around as well.

>       xdvik, bibview, xtexcad, transfig 

What is xdvik?  Is that a type of xdvi, or is that an enhancement?  
Is xtexcad stable now?  The last time I used it (a long time ago) it
segfaulted whenever I sneezed.  

From debian-devel@pixar.com Mon Mar 28 16:29:31 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA10624; Mon, 28 Mar 94 16:29:27 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plOmn-0005r6a; Mon, 28 Mar 94 13:23 PST
Date: Mon, 28 Mar 94 13:23 PST
Message-Id: <199403282123.AA20646@masi.ibp.fr>
Errors-To: bruce@pixar.com
Reply-To: Remy.Card@masi.ibp.fr
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Remy.Card@masi.ibp.fr (Remy CARD)
To: debian-devel@pixar.com
Subject: YAP (Yet Another Proposal)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO



	Hi,

	While reading Stephen White's proposal, I have thought of another
solution to the problem.  BTW, my solution seems so simple and changes so
few things that I must be wrong somewhere :-)  If so, please explain
*kindly* why I am wrong.

	The purpose of both proposals (Ian Jackson's and Stephen White's
ones) is to allow cooperating users to use 002 as a umask to share common
files while they keep their own files private in their home directories.

	I suggest a third way to achieve this goal.  Suppose that we have
the following directory tree:

	/home/card	(card,users)
	/home/jackson	(jackson,users)
	/home/white	(white,users)
	/home/proj1	(anybody,proj1)
	/home/proj2	(anybody,proj2)

	To allow users to share files in proj1, we make them members of
the group `proj1'.  Ditoo for proj2.

	Now, we have to prevent files created in home directories to be
readable and writable by users belonging to the same group.  I suggest that
we use the permissions set on home directories.  If we create home directories
with mode 700, nobody will be allowed to access others' files.  Thus, this
scheme does not imply private groups.

	I agree that my scheme is different from Mr Jackson's one, in theory
but it should have the same practical effect.  The only major difference is
that my proposal does not allow `others' to read or write files but I don't
think that this is worth considering.  After all, if you create private
groups to restrain members of your group to access your files, you probably
do not want any other user to access them.

	It seems to me that this scheme can lead to the same results as
Ian Jackson's and Stephen Whites's proposals.  Of course, as I said above,
this seems so simple that I must be wrong.  Feel free to correct me if I am
wrong or if this solution has been discussed before (but try to stay cool and
don't start another flamewar :-)

--
Remy Card
card@masi.ibp.fr

"Maybe we're lying and you'd better not stay"

From debian-devel@pixar.com Mon Mar 28 17:00:46 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA10965; Mon, 28 Mar 94 17:00:44 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plPH3-0006Fca; Mon, 28 Mar 94 13:55 PST
Date: Mon, 28 Mar 94 13:55 PST
Message-Id: <9403282154.AA06668@trcsun3.eas.asu.edu>
Errors-To: bruce@pixar.com
Reply-To: deisher@enws125.eas.asu.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: deisher@enws125.eas.asu.edu (Michael E. Deisher)
To: debian-devel@pixar.com
Subject: Re: YAP (Yet Another Proposal)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Remy Card writes:
> 	Now, we have to prevent files created in home directories to
> be readable and writable by users belonging to the same group.  I
> suggest that we use the permissions set on home directories.  If we
> create home directories with mode 700, nobody will be allowed to
> access others' files.  Thus, this scheme does not imply private
> groups.

I help administer a network of Sun Sparcstations and PCs in a research
lab at ASU.  As the default we create all new accounts with world read
permission (mode 755) on each new user's home directory.  We do this
because we believe it fosters cooperation and sharing of information.
Also, it makes it easier for us (the system administrators) since we
can just answer newbies by saying, "look at my .foobarrc file" or
"copy my classproject.tex file" instead of stopping to e-mail it.
Most times questions are eliminated altogether because people can use
find and grep to get what they need.  Therefore, I hate to see the
Debian default mode for home directories be 700.

Just my 0.5 cents.  :-)

--Mike

 ==============================================================================
  |  Mike Deisher                                  Arizona State University  |
  |  deisher@dspsun.eas.asu.edu          Telecommunications Research Center  |
  |  voice:  (602) 965-0396                    Signal Processing Laboratory  |
  |  fax:    (602) 965-8325                           Tempe, AZ  85287-7206  |
 ==============================================================================

From debian-devel@pixar.com Mon Mar 28 20:13:52 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA12024; Mon, 28 Mar 94 20:13:49 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plS7P-0005qra; Mon, 28 Mar 94 16:57 PST
Date: Mon, 28 Mar 94 16:57 PST
Message-Id: <Pine.3.89.9403282208.B925-0100000@budge.apana.org.au>
Errors-To: bruce@pixar.com
Reply-To: charlieb@budge.apana.org.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: <charlieb@budge.apana.org.au>
To: debian-devel@pixar.com
Subject: Re: Berkeley (was UUCP)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


On Sun, 27 Mar 1994, Robert Sanders wrote:
> 
> As for the new db, well, I don't think it's even source compatible
> with ndbm/gdbm.  It may be the best thing since sliced bread, but
> gdbm is what's in the shared library, and it works pretty well
> for me.

Is it free of size restrictions? It's all very well saying it works 
pretty well for you - that might just be you haven't yet come across the dbm 
size limitation. But I'd expect the GNU version to be OK...

Charlie Brady * (W) charlieb@tplrd.tpl.oz.au * (H) charlieb@budge.apana.org.au
"Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
  but no simpler"   Einstein, A  | Fax: (02) 413 6868 Pacing Systems    \/  



From debian-devel@pixar.com Mon Mar 28 20:35:44 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA12129; Mon, 28 Mar 94 20:35:41 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plScw-0006Bja; Mon, 28 Mar 94 17:29 PST
Date: Mon, 28 Mar 94 17:29 PST
Message-Id: <199403290128.LAA01338@extra.ucc.su.OZ.AU>
Errors-To: bruce@pixar.com
Reply-To: matth@ucc.su.oz.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Matthew Hannigan <matth@ucc.su.oz.au>
To: debian-devel@pixar.com
Subject: Re: YAP (Yet Another Proposal) 
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


Remy.Card@masi.ibp.fr (Remy CARD) writes:
> [ restrictive permissions on home dirs to avoid
> requirement for private groups ]

Yes, this will work.  But the downside that you mention is to me
too onerous. You cannot change your home dir permission without
being very careful how about who you are letting in.

--
	-Matt

From debian-devel@pixar.com Tue Mar 29 00:07:07 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA13274; Tue, 29 Mar 94 00:07:04 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plVvd-0005rsa; Mon, 28 Mar 94 21:01 PST
Date: Mon, 28 Mar 94 21:01 PST
Message-Id: <9403290459.AA01706@spiff.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: Documentation of the private groups proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

   Date: Sun, 27 Mar 94 17:27 PST
   From: iwj10@cus.cam.ac.uk (Ian Jackson)

   The right time to be writing documentation is IMO in the period where
   the beta testers are finding bugs, after the major design issues have
   settled down.

It is probably appropriate to mention in this thread that Matt Welsh
has offered to help document Debian as soon as this point has been
reached.  Ian is quite right, and that is exactly the reason I have
told Matt not to even to bother starting until the major design issues
have been settled.  Debian veterens will recall that 0.91 was not even
remotely like any of the ALPHA versions; in fact, 0.04 ALPHA to 0.80
BETA involved a complete rewrite of the entire packaging system.  Try
to imagine what it would have been like to modify the entire
documentation set to reflect the changes.  0.91 to 0.92 is also going
to be quite a change, as you shall soon see...

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Tue Mar 29 00:14:21 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA13336; Tue, 29 Mar 94 00:14:18 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plW2e-0005qXa; Mon, 28 Mar 94 21:08 PST
Date: Mon, 28 Mar 94 21:08 PST
Message-Id: <199403290501.AA28029@prism.gatech.edu>
Errors-To: bruce@pixar.com
Reply-To: gt8134b@prism.gatech.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: gt8134b@prism.gatech.edu (Robert Sanders)
To: debian-devel@pixar.com
Subject: Re: Berkeley (was UUCP)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


charlieb@budge.apana.org.au writes:
> On Sun, 27 Mar 1994, Robert Sanders wrote:
> > As for the new db, well, I don't think it's even source compatible
> > with ndbm/gdbm.  It may be the best thing since sliced bread, but
> > gdbm is what's in the shared library, and it works pretty well
> > for me.
> 
> Is it free of size restrictions? It's all very well saying it works 
> pretty well for you - that might just be you haven't yet come across the dbm 
> size limitation. But I'd expect the GNU version to be OK...

Well, that was a personal testimonial supporting my more general point
(perhaps unstated :-) that gdbm seemed good enough for general use, its
strongest advantage over BSD4.4 db being the dbm and ndbm compatibility.
Keeping the standard Linux system dbm library gdbm doesn't preclude the
use of BSD4.4 db, of course. 
 
>From the gdbm 1.7.1 Info pages:

Introduction to GNU `dbm'.
**************************

   GNU `dbm' (`gdbm')is a library of database functions that use
extendible hashing and works similar to the standard UNIX `dbm'
functions.  These routines are provided to a programmer needing to
create and manipulate a hashed database. (`gdbm' is *NOT* a complete
database package for an end user.)

   The basic use of `gdbm' is to store key/data pairs in a data file.
Each key must be unique and each key is paired with only one data item.
The keys can not be directly accessed in sorted order.  The basic unit
of data in `gdbm' is the structure:

       typedef struct {
                  char *dptr;
                  int  dsize;
               } datum;

   This structure allows for arbitrary sized keys and data items.

   The key/data pairs are stored in a `gdbm' disk file, called a `gdbm'
database.  An application must open a `gdbm' database to be able
manipulate the keys and data contained in the database. `gdbm' allows
an application to have multiple databases open at the same time.  When
an application opens a `gdbm' database, it is designated as a `reader'
or a `writer'.  A `gdbm' database opened by at most one writer at a
time.  However, many readers may open the database open simultaneously.
 Readers and writers can not open the `gdbm' database at the same time.

[...]

Compatibility with standard `dbm' and `ndbm'.
*********************************************

   GNU `dbm' files are not `sparse'. You can copy them with the UNIX
`cp' command and they will not expand in the copying process.

   There is a compatibility mode for use with programs that already use
UNIX `dbm' and UNIX `ndbm'.




From debian-devel@pixar.com Tue Mar 29 02:00:24 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA13611; Tue, 29 Mar 94 02:00:21 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plXhG-0005rca; Mon, 28 Mar 94 22:54 PST
Date: Mon, 28 Mar 94 22:54 PST
Message-Id: <199403290653.AA09543@SunSITE.Unc.EDU>
Errors-To: bruce@pixar.com
Reply-To: mdw@sunsite.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw@sunsite.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Documentation of the private groups proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

> It is probably appropriate to mention in this thread that Matt Welsh
> has offered to help document Debian as soon as this point has been
> reached.  Ian is quite right, and that is exactly the reason I have
> told Matt not to even to bother starting until the major design issues
> have been settled.  

That's what I'm waiting for. What I'd like to do is release a Debian-specific
I&GS (and perhaps make that the "only" I&GS once Debian's foothold is strong
enough to call it the "official" Linux distribution). But, of course, I
can't start to document those things until you have a ready-to-install 
package. Of course I'm more than willing to write code for the Debian 
installation process. I'd like for it to be as smart and seamless as possible.
That doesn't necessarily mean using colour menus. :) 

How much is there in the way of installation scripts, and what needs to
be done? Would it be worthwhile to either a) Write a smarter front-end
for fdisk, or b) Write a commandline-driven fdisk than can be executed
semi-automatically from any front-end? If this is a good idea I can do it.

Also, I'd like to document Debian as a whole; that is, keep lists and
logs of each software package in the distribution, software versions,
and ChangeLogs from one version to the next. 


From debian-devel@pixar.com Tue Mar 29 15:50:53 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA17766; Tue, 29 Mar 94 15:50:51 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plkex-0008NSa; Tue, 29 Mar 94 12:45 PST
Date: Tue, 29 Mar 94 12:45 PST
Message-Id: <m0plkK6-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: YAP (Yet Another Proposal)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Remy Card proposes (unless I'm mistaken) that under a umask of 002
people should protect their files from abuses by those who happen to
be members of the group which owns their home directory by changing
the mode of their home directory to 700 !

I'm rather shocked to find Remy Card coming up with something which is
IMO so ill-considered.

People usually want to have the majority of their files visible to
(readable by) most of the rest of the users.  This involves giving
everybody at least `rx' access to all of your directories.

It's not a `solution' to the problem that other people whom you wish
to be able to read but not write your files can write them to arrange
for those people to be unable to access them at all !  Err, sorry
about that nasty nested sentence ...

Also, of course, applications like `finger' require the user's home
directory to be at least ?11 so that the .plan and .project are
visible.  This makes the whole thing very difficult to maintain
securely.

Ian.

From debian-devel@pixar.com Tue Mar 29 17:02:48 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA18726; Tue, 29 Mar 94 17:02:19 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pllm8-000748a; Tue, 29 Mar 94 13:56 PST
Date: Tue, 29 Mar 94 13:56 PST
Message-Id: <9403292150.AA22634@spectrum.cs.bucknell.edu>
Errors-To: bruce@pixar.com
Reply-To: quinlan@spectrum.cs.bucknell.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan)
To: debian-devel@pixar.com
Subject: Re: YAP (Yet Another Proposal)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

iwj10@cus.cam.ac.uk (Ian Jackson) writes:

> Remy Card proposes (unless I'm mistaken) that under a umask of 002
> people should protect their files from abuses by those who happen to
> be members of the group which owns their home directory by changing
> the mode of their home directory to 700 !

> I'm rather shocked to find Remy Card coming up with something which
> is IMO so ill-considered.

Well, it wasn't THAT bad.  I've made more than one "ill-considered"
proposal in my time.  :-)

> [ more arguments against ]

Yep.

> Also, of course, applications like `finger' require the user's home
> directory to be at least ?11 so that the .plan and .project are
> visible.  This makes the whole thing very difficult to maintain
> securely.

Well, `finger' shouldn't really require a user's home directory to be
?11.  (And there are decent (albeit somewhat complicated) ways to get
around this.)  The reasoning is that a user should be able to set his
directory to be ?00 and still have their .plan and .project readable
via `finger' and only `finger'.

Dan

--
Daniel Quinlan  <quinlan@spectrum.cs.bucknell.edu>

From debian-devel@pixar.com Tue Mar 29 20:03:45 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA19728; Tue, 29 Mar 94 20:03:42 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plobf-000A0Ua; Tue, 29 Mar 94 16:58 PST
Date: Tue, 29 Mar 94 16:58 PST
Message-Id: <9403300056.AA11340@spiff.gnu.ai.mit.edu>
Errors-To: bruce@pixar.com
Reply-To: imurdock@gnu.ai.mit.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@gnu.ai.mit.edu
To: debian-devel@pixar.com
Subject: Debian bootdisk issues
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

I'm working on the bootdisk and I'd like a few opinions.  Several
people have mentioned that non-US keytables should be available at
install time.  I agree completely, but unfortunately there is not much
room to spare on the bootdisk.

Is it worth going back to boot/root disks for 0.92 to accommodate this
(and to allow a few other programs to be included on the bootdisk,
such as vi)?  It seems to be the only way...

Ian Murdock <imurdock@gnu.ai.mit.edu>

From debian-devel@pixar.com Tue Mar 29 20:23:03 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA19814; Tue, 29 Mar 94 20:22:59 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plouK-000A03a; Tue, 29 Mar 94 17:17 PST
Date: Tue, 29 Mar 94 17:17 PST
Message-Id: <9403300114.AA23833@nyx10.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: dminer@nyx10.cs.du.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: dminer@nyx10.cs.du.edu (Dan Miner)
To: debian-devel@pixar.com
Subject: Re: Debian bootdisk issues
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

According to imurdock@gnu.ai.mit.edu:
> 
> I'm working on the bootdisk and I'd like a few opinions.  Several
> people have mentioned that non-US keytables should be available at
> install time.  I agree completely, but unfortunately there is not much
> room to spare on the bootdisk.
> 
> Is it worth going back to boot/root disks for 0.92 to accommodate this
> (and to allow a few other programs to be included on the bootdisk,
> such as vi)?  It seems to be the only way...

Isn't the keymaps on the base disk(s)?  That could be a "fair"
compromise.  Having the boot/root configuration makes having
the multiple kernel images a little harder to do.  Unless
you use an fs and lilo and make sure the kernel will pause
for booting a separate root image.  [And you will have 4 disks
to worry about if done that way.  boot/root/2 bases]

		Dan

-- 
Dan Miner					dminer@nyx.cs.du.edu
	"The longer I stare at this screen; the blanker it gets."
						Linux: try it, you'll like.
"Your program is encoded in pi."		I started with a 64

From debian-devel@pixar.com Tue Mar 29 20:33:04 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA19893; Tue, 29 Mar 94 20:32:57 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plp3y-000A0na; Tue, 29 Mar 94 17:27 PST
Date: Tue, 29 Mar 94 17:27 PST
Message-Id: <199403300122.AA05284@prism.gatech.edu>
Errors-To: bruce@pixar.com
Reply-To: gt8134b@prism.gatech.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: gt8134b@prism.gatech.edu (Robert Sanders)
To: debian-devel@pixar.com
Subject: Re: Debian bootdisk issues
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO


imurdock@gnu.ai.mit.edu writes:
> I'm working on the bootdisk and I'd like a few opinions.  Several

Well, no opinion about the keytables, but I did want to let you know
that the QIC-02 probe at boottime hoses SMC8013 cards, which makes
an NFS install more problematic.  I don't see any "command line"
parameters to the kernel that could turn off QIC-02 probing (but I
just skimmed it), but something should probably be done.



From debian-devel@pixar.com Tue Mar 29 20:38:58 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA19925; Tue, 29 Mar 94 20:38:54 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plp9i-000A0La; Tue, 29 Mar 94 17:33 PST
Date: Tue, 29 Mar 94 17:33 PST
Message-Id: <9403300129.AA25933@nyx10.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: dminer@nyx10.cs.du.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: dminer@nyx10.cs.du.edu (Dan Miner)
To: debian-devel@pixar.com
Subject: Re: Debian bootdisk issues
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

According to Robert Sanders:
> 
> 
> imurdock@gnu.ai.mit.edu writes:
> > I'm working on the bootdisk and I'd like a few opinions.  Several
> 
> Well, no opinion about the keytables, but I did want to let you know
> that the QIC-02 probe at boottime hoses SMC8013 cards, which makes
> an NFS install more problematic.  I don't see any "command line"
> parameters to the kernel that could turn off QIC-02 probing (but I
> just skimmed it), but something should probably be done.

I had a problem with it probe too.  I don't have any such devices
and it got mad.  :)  Filled my screen with something about
0xf or 0xff.  I ditched the kernel ASAP and I can't remember
the actual message.   Ah, well....

		Dan

-- 
Dan Miner					dminer@nyx.cs.du.edu
	"The longer I stare at this screen; the blanker it gets."
						Linux: try it, you'll like.
"Your program is encoded in pi."		I started with a 64

From debian-devel@pixar.com Tue Mar 29 07:57:08 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA14135; Tue, 29 Mar 94 07:57:05 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0pldGU-0005q2a; Tue, 29 Mar 94 04:51 PST
Date: Tue, 29 Mar 94 04:51 PST
Message-Id: <m0plSvm-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Documentation of the private groups proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

Bill Mitchell writes:
> I wasn't directing my remarks specifically at anything Ian had said.

Oh, sorry, I suppose all the rather personally oriented debate
recently has made me jump to conclusions.

> ... it would be inappropriate for the
> victorious faction to breathe a sigh of releif and go on to other things
> once the issue is decided.

Speaking personally, it would be more accurate to say that now that
the issue has (practically) been decided I may have a better chance of
finding time to update the manpages to document setgid directories and
BSD semantics.  I don't have to spend quite so much time debunking
what I see as spurious arguments against the IMO reasonable course
that's now being taken (modulo problems with the default).

When I've seen 0.92 I'll write an admin supplement for it, unless
someone would rather do it. (please!)

> I recall much argument here about what these changes do and do not do,
> what effect they do and do not have, what protections they do and do
> not offer, how they are or are not intrusive on unintrested users, and
> what an interested user does and does not need to do in order to take
> advangage of these changes.  I doubt that even those reading all the
> debian lists will remember all of that -- much less users who will get a
> copy of debian 0.92beta without having seen all the discussions in all
> the lists.

I firmly believe - and have much evidence for doing so - that even if
the fact that user private groups are in use (assuming they are by
default - please let them be!) is documented nowhere else but
adduser(8) and /etc/adduser.conf then there will be at the very most
very few problems, and that even those will be minor.

If it's not the default then IMO some documentation will be needed to
tell people to turn the option on so that they do not end up with e.g.
/usr/local/man trees with bizarre and inconsistent permissions, and so
that forthcoming software for management of groups by ordinary users
will actually work properly for all users.

However, this issue is certainly something that should be covered in a
section of the Debian Administrators' Supplement, along with security
policy in general.

Ian.

From debian-devel@pixar.com Tue Mar 29 02:00:24 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
	id AA13611; Tue, 29 Mar 94 02:00:21 EST
Received: from mongo by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0plXhG-0005rca; Mon, 28 Mar 94 22:54 PST
Date: Mon, 28 Mar 94 22:54 PST
Message-Id: <199403290653.AA09543@SunSITE.Unc.EDU>
Errors-To: bruce@pixar.com
Reply-To: mdw@sunsite.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw@sunsite.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Documentation of the private groups proposal
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO

> It is probably appropriate to mention in this thread that Matt Welsh
> has offered to help document Debian as soon as this point has been
> reached.  Ian is quite right, and that is exactly the reason I have
> told Matt not to even to bother starting until the major design issues
> have been settled.  

That's what I'm waiting for. What I'd like to do is release a Debian-specific
I&GS (and perhaps make that the "only" I&GS once Debian's foothold is strong
enough to call it the "official" Linux distribution). But, of course, I
can't start to document those things until you have a ready-to-install 
package. Of course I'm more than willing to write code for the Debian 
installation process. I'd like for it to be as smart and seamless as possible.
That doesn't necessarily mean using colour menus. :) 

How much is there in the way of installation scripts, and what needs to
be done? Would it be worthwhile to either a) Write a smarter front-end
for fdisk, or b) Write a commandline-driven fdisk than can be executed
semi-automatically from any front-end? If this is a good idea I can do it.

Also, I'd like to document Debian as a whole; that is, keep lists and
logs of each software package in the distribution, software versions,
and ChangeLogs from one version to the next. 


