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@xxxxxxxxx
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
