on being an ass Re: [Gnu-arch-users] Re: Linus

[Tom Lord]

    >>>> From: Ethan Benson
    >>>> as i have pointed out, sysadmins worth thier salt are not going
    >>>> to allow shared accounts with multiple having access to it.

    >> From: Tom Lord
    >> Yeah, the suid bit was just a joke.  Nobody was meant to actually
    >> _use_ it.

    > From: Ethan Benson
    > you are doing an EXCELLENT job of chasing away users, developers, and
    > donations with your asshole attitude.

    > and i was considering sending you a donation shortly.  not anymore.

A more constructive reply might have gone:

"D'oh -- I forgot about that (and about daemon accounts and about the
 many programs that work best when you given a purpose-specific uid).
 Yeah, yeah, yeah: bad way to express the point.

 But you _do_ know what I'm talking about, smartass, right?
 Especially on large systems: Adding "special" user ids like that is a
 rare thing and they're created as _exceptions_ to the general
 practice.  Meanwhile, user accounts are handled very carefully with
 plenty of auditing: admins want to associate each user account with
 particular real world human; they typically have auxiliary databases
 for that purpose and administrative scripts that assume it; they like
 to deprecate old accounts in a timely and controlled way; they like
 to conduct security-problem post mortems by looking at who was logged
 in when.  Even "Terms of Use" policies -- entities whose construction
 involves a much larger group of people than just the sysadmins -- are
 typically built with that 1:1 association between accounts and users
 in mind.

 It's ridiculous to expect a large organization like OSU or
 SourceForge or Savannah to drop everything and revise all of that
 technical, social, and legal infrastructure just so that any user who
 wants to start an arch project can allocate a new user id.

 Get it?!?!"

To which I might have had opportunity to say something like:

 I agree with your observations about how large systems are generally 
 set-up but not with the conclusion that all of that stuff would need
 to change or the conclusion that allocating ids for archive access
 is ridiculous.

 I'll say at the outset that the biggest drawback I see is the
 increase in UID consumption: systems that are pushing those limits
 already have a good reason not to be too fond of this approach.
 Overall, a trivially customized arch-sftp ssh subsystem is, from what
 I've seen so far, the lowest impact solution.   I can imagine close
 runner-ups like a multi-user-name UID which chroots to a directory
 selected by the user name (i.e., exactly one "special account" for
 all arch projects).   This entire space of alternative approaches 
 is quite competitive with the admin impact of hosting a CVS farm.

 If the project-user-account approach is to be taken, I don't think it
 requires a revolution in administration policies.  These wouldn't be
 general user accounts -- they don't need a login shell and they can
 be restricted to running exactly one program in a chroot jail.
 Access to them would be ssh-based.  There's potentially a slight loss
 in security auditting but it wouldn't take much to fix even that.
 Legally, they'd be covered by the same protections that currently
 cover things like connecting to ports 21 or 25.  It _looks_
 superficially different since there's this issue of adding and
 removing ssh keys to the accounts -- and that _suggests_ that these
 accounts are somehow "user accounts" -- but really, they only thing
 they'd be good for is some file operations in chroot-ed sandbox that
 can even be quota protected.  It's really up to project owners who
 gets to install a key for a given project.  I don't see how this is
 all that different from letting people grant anonymous FTP access by
 creating ~/FTP or set up their own corner of the web in ~/WEB.

 But anyway, some of the bottom lines:

 * with a custom ssh service, there's no need for additional accounts
   at all.

 * we could make good use of having just _one_ new UID, using various
   user-names for that ID to distinguish which arch project is being
   accessed (and chroot appropriately)

 * if it's preferable, setting up limited-use users per-project is
   also easy and causes no problems.; heck if we have enough user ids,
   we could just give one to every developer for each project he's a 
   committer to.

 In each case, the new administrative burden is no greater than, 
 possibly quite a bit less than, the burden of trying to administer
 a huge CVS farm.   And what's more:  the consumption of cycles
 and disk bandwidth by a gazillian arch users is almost certainly 
 much less than consumption by a gazillian CVS users;  consumption of
 network bandwidth is at least competitive.    If anything, it makes
 sense from the admin perspective to set this up and _encourage_
 people to use arch.


But instead of such an exchange we get:

    > From: Ethan Benson

    > Tom seems to be a childish, whiny loser too pathetic to get a
    > real job so instead spends all day begging for free money while
    > being an asshole to anyone dumb enough to fall for it.

    > just paying back the ad hominems.

Yup.  That's me all over.  :-)

Obviously I'm not fond of losing financial support.  At the same time,
I do my best not to let financial support screw up the engineering and,
in this case, not to let people "buy a gnu-arch-users soapbox" from
which they an spread misinformation.

Ethan was wrong on the technical issues.   That's no big deal.   Ethan
was repeatedly insistent about the things he was wrong about, relying
on phrases like "sysadmins worth thier salt are not going to
allow...." rather than reasoned argument.   Honestly, I don't think I
was particularly unkind to him in the responses that drew that
reaction -- but there's no accounting for taste, I guess.

Perhaps this is a good time to whine and beg a little:

-t

https://www.paypal.com/xclick/business=lord%40emf.net&item_name=support+for+arch+and+other+free+software+efforts+by+tom+lord&no_note=1&tax=0&currency_code=USD