On 08/27/2014 05:09 PM, jblist_at_icloud.com wrote:
>
> On Aug 27, 2014, at 8:28 AM, Zé <jose.passes_at_gmx.com> wrote:
>
>> Additionally, to those security-concious people, installing servers
>> on your workstation just to access local repositories isn't exactly
>> on the top of best practices. Don't you agree?
>>
>
>
> Not at all. Running a "server" which only answers to calls via the
> loopback interface (or local-domain sockets) is quite common. In
> fact, look at your machine's own process list. You will find a large
> number of helper processes that run with UIDs other than as root.
Those processes tend to be configured by people who had to invest
significant amounts of time and effort to know what they were doing.
I don't believe this should not be expected, let alone required, from
end-users who only wish to get a basic tool to perform a basic task. In
fact, I'm not aware of a single version control system which forces that
on anyone who only wishes to, say, keep track of the changes applied to
a directory tree.
> The point of separating your repository access to a "server" process
> allows you to insulate file access permissions to one UID separate
> from your own (priviledge separation). If all users on a single box
> access the repository through this "server" process, you create a
> layer of abstraction and prevent file ownership/permissions flipping
> and actually _increase_ security and preserve the integrity of your
> repo.
My point is that in a significant number of cases, "all users on a
single box" means "a singleuser on a single box, who already has
complete access to the repo files".
It makes no sense to argue for these hurdles if they actually don't
accomplish nothing. This means that all the requirements to learn and
waste time configuring and managing servers aren't justified.
Meanwhile, there are plenty of version control systems out there that
don't impose any of these requirements.
Zé
Received on 2014-08-28 10:09:54 CEST