Les Mikesell wrote:
John Summerfield wrote:
Nobody should have the ability to update code owned by the next
stage.
That's not possible with most version control systems. Everyone has
It's essential. You don't want everyone to be able to mess with
production code.
I meant that no one ever changes anything that has ever been
committed. Everyone makes changes in their own workspace and a
commit becomes a new revision. Anyone can check out any revision
that has ever been committed. So, each stage checks out their own
appropriate revision or tagged copy based on the workflow regardless
of what else is happening in the repository. It doesn't matter that
someone can check in garbage, what matters is that the garbage
revision not the one that QA tests/approves/tags to go to production.
How do you propose minimising the possibility of someone of ill intent
making unauthorised changes?
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?
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.
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:
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.
Any number of people could be given access to resources.
SQL has some fairly simple, effective primitives for controlling access
to tables.
If I want to give an individual access to a file I am authorised to
grant access to, then all I need to know is the name of my file, and the
userid of the user. And the command.
If you don't trust your file access control, these don't matter much.
Nobody should trust anything they're not forced to: that's what
Microsoft means when it talks of "trusted computing."
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.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
Please do not reply off-list
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
