gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Arch hooks


From: Tom Lord
Subject: Re: [Gnu-arch-users] Arch hooks
Date: Tue, 30 Sep 2003 10:38:17 -0700 (PDT)

    > From: "Stephen J. Turnbull" <address@hidden>

    > Realistically, hook scripts in project trees are only mildly
    > dangerous.

That's a very context-specific assertion.  In general, they are a
nightmare.  If the danger doesn't worry you, consider the portability
issues.  Consider (quite realistic, I assure you) situations where
revision control is used to coordinate source streams from hundreds or
thousands of, at most, "semi-vetted" sources.

But in a sense you're right:  There's two questions that have become
confused but that should be separated:

        1) where do hook scripts get stored?

        2) by what mechanisms is execution of hook scripts authorized
           by a user

My concerns are really about (2) but not so much (1).   They were
expressed poorly in that they confused the two issues.   My
inclination towards a solution to (2) is where (1) comes into play.

What I really don't want is a situation in which users are surprised
when some arch operation executes a shell script they knew nothing
about.   It has to require positive action on the part of a user to
authorize executing a script that might have come from a third party.
The nature of that positive action is comperable to "give so and so
access to my machine and my password".

How should such authorization be managed?  What's the user interface
to it?  One idea is to let users grant permission expressed in terms
of project names and so forth.... my intuition is that that is a hairy
nightmare.  Another idea is to let users maintain a separate "hooks
tree" -- which may or may not include sources downloaded from third
parties.  The latter idea has the advantage that it is simple,
infinitely flexible, easy to understand, and avoids the hair of trying
to embed in arch a security model for hooks.  That's why I linked (2)
to (1) without explanation -- it seemed obvious to me.

-t






reply via email to

[Prev in Thread] Current Thread [Next in Thread]