[Fedora] Re: Semi OT: Subversion

Les Mikesell lesmikesell at gmail.com
Thu Nov 8 20:03:52 UTC 2007


John Summerfield wrote:

>> With revision control systems, you always have access to all versions 
>> and the ability to see the differences between them and who made the 
>> changes (most useful with text/source).  If something is important, 
>> I'd expect someone to review the changes as well as performing 
>> functional tests on any generated programs.
> 
> If I, a developer, can modify the repo outside the vcs system (which is 
> what I said earlier), how then do you, in Production Control, guarantee 
> its content?

I don't see how this issue relates to the VCS system all all.  If you 
have access to change files, you can change files whether they are the 
production copy or some preliminary version.  But the first rule to 
avoid it would be to not give physical access to the machine holding the 
repo to anyone you don't trust, and that includes the backup tapes that 
might be used to reconstruct it. Next would be to avoid filesystem 
access by anyone you don't trust.  Since we are talking about 
subversion, that means using https or svnserve to access the repo.  Even 
disregarding the access control those network services provide, nothing 
you can do through the client api will ever change an existing repo 
revision.  You can only commit new revisions and it will be possible to 
check the differences against the old.

Even if you do have filesystem access, making a change in the repo 
history would be non-trivial since the storage format is based on diffs 
against other revisions and there will most likely be many remote 
workspaces that expect specific things to be in their pegged revisions 
or tag copies, and someone would notice any change.

>>> Think what DoD, any big bank, Qantas, Westfield or any other 
>>> significant business would expect?
>>
>> Don't they outsource everything these days?
> 
> Hardly relevant. I don't think we do.

It's relevant in terms of what you know about what you should trust.

>>>> You've got unix filesystem permissions and SELinux at your disposal 
>>>> to control direct repository access.  And the repository doesn't 
>>>> have to be on the same machine as any of the users.
>>>
>>> Unix is weak. selinux is cumbersome.
>>
>> Compared to?  How could you tell if something else is better?
> 
> Compared with tools I used in the 80s on another platform:

How could you tell?

> I used ACF/2 before it was CA-ACF2, and I can't find docs to refresh my 
> mind.
> 
> Here's how to create two TSO users on z/OS:
> 
> ADDUSER (PAJ5 ESH25)
> 
> A TSO user has equivalent access to z/OS as a shell user has in Linux.
> There's much more that one can specify, see 
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICHZA441/5.3?DT=20040416130942 
> 
> 
> To create a group:
> ADDGROUP PROJECTA
> See 
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICHZA441/5.1?DT=20040416130942 
> 
> 
> To connect a user to a group:
> connect ESH25 group(projecta)
> Note case is not significant.
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICHZA441/5.7?SHELF=&DT=20040416130942&CASE= 
> 
> 
> Give projecta members update access to a file, WJE10.DEPT2.DATA
> PERMIT 'WJE10.DEPT2.DATA' ID(RESEARCH) ACCESS(UPDATE)
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICHZA441/5.17?SHELF=&DT=20040416130942&CASE= 
> 
> 
> There are many things that _can_ be specified.

But how can you prove that they are better than the unix user/group 
concepts?

> Any number of people could be given access to resources.

As is the case in unix which can have any number of groups.

>> Why trust the people supplying something they happen to call "trusted"?
>>
> As I explained, at some point you must. Even then, you take every care. 
> z/OS users trust IBM because IBM has a good reputation, and because they 
> must. Even though the IBM software's imperfect.

I start with the assumption that a certain number of lines of code will 
statistically have a certain number of accidental flaws, and that 
anything to do with authentication and access control will have some 
probability of having intentional backdoors embedded.  With the unix 
uid/group concepts you can sort-of understand what login/su/setuid 
should be doing, and what has to happen during open(), which in unix is 
necessary to get access to anything.  Even without wading through this 
code myself, I can have a certain amount of faith that the people who 
make changes and review this code can get it right most of the time and 
that any intentional backdoors would be noticed.  I have no such faith 
in any of the more complex and less publicly scrutinized mechanisms, 
although I would be open to anyone trying to show why such faith would 
be justified.

-- 
   Les Mikesell
     lesmikesell at gmail.com




More information about the fedora-list mailing list