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

Re: [Fedora] Re: Semi OT: Subversion



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 gmail com


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