Re: [Gnu-arch-users] Re: Linus

[Colin Walters]

On Mon, 2003-10-13 at 13:37, Tom Lord wrote:

> I gather that on this system with highly restrictive admin policies
> you nevertheless have a shell account, right?   Therefore, why not,
> instead of invoking the sftp subsystem directly, write a client-side
> program that invokes ssh and sends some commands that adjust your
> umask and exec an sftp server?

Sure.  More custom code to write for every client.

> You're between a rock and a hard place here:
> 
> rock: sysadmins of an important machine who have some established
>       practices 
> hard place: a valuable project that is being carefully engineered

Yes.

> Which of those "weighs more" in your mind?  Both have legitimate
> interests and, at a quick glance, you decided they were in conflict.
> (The solution suggested above may make the conflict disappear,
> though.)
> 
> Who is to be master?  In _mere_anticipation_ of the admins refusing to
> help you (and even laughing in your face) you're proposing to
> compromise the engineering of arch.  Sorry -- I'm not buying it.

And *this* is our disagreement.  I don't see copying permissions to be
"compromising the engineering of arch".  Sorry.  In fact, quite the
opposite - I think requiring people to use ssh for multiple committers
is compromising the filesystem-independence of arch, which is certainly
a large component of its engineering.

> [...] I _know_ that help
> from the admins on this issue will:
> 
>       *) Cost them almost no work

If you were a system administrator, you'd know that there is a vast
chasm between "almost no work" and "no work".  When you have "almost no
work" and multiply it by a large number of people, it ends up being real
work.

> Mostly I think you should just get over it.  Don't _assume_ that you
> have no opportunity to make reasonable requests of the admins (though
> you probably don't need to make any in this case).  

Look man, I worked there for a year, I know what they will consider
reasonable and what they won't.

> Heck, as far as
> I'm concerned -- if they're managing a 3k user environment?  Extra
> accounts (not necessarily fully general user accounts, but extra uids)
> should be available like candy.  

It's just not that simple.

> In any event: at your site, the ssh wrapper proposed above should
> solve the umask problem -- without any extra accounts, ssh subsystem
> hacking, or anything.

It might, yes.  But we can put a little more intelligence into arch and
not force everyone to hack up ssh subsystem scripts for all time.

Anyways, this discussion is getting repetitive and boring.  Honestly, I
don't care much about it.  I'd rather push my patch queue manager as a
solution to this problem :)