On Wed, 23 Mar 2011 23:46:14 -0400, Jerry Stuckle
<jstucklex (AT) attglobal (DOT) net> wrote:


Well.... that sux

Sounds like a custom app solution is in order.

-Dr.X

Storage rights in the external storage is very controversial decision.
In any case, will be an additional layer of paper with a database
that, immediately below the index of reliability of the system as a
whole. Plus, in any case this (perhaps minimally) affect the
productivity and performance.

Jerry Stuckle <jstucklex (AT) attglobal (DOT) net> wrote:
[full quote snipped]

Bleh. I know all this.

Still the question is: if you have a database server that get hundreds
of login requests per second - do you really want to transfer GRANT
records (that can be from a dozen up to some hundred) from the
dictionary to the MySQL server for each single access?

In most cases the answer is "No"

But when you accept that, then you can as well have your central
repository of GRANTs and roll them out (automated, of course) to the
servers as needed. Say if HR moves Mr. Jerry S. from the database group
to facility management, they can strip the database permissions from
his dictionary entry and hit the magical "Synchronize With World"
button. In fact the same would work with passwords. And indeed many
companies implement it in a way where the central password dictionary
is pushed to edge servers only once a day or so.

I must also say that it is very uncommon to give permissions on the
SQL level to physical person accounts. Most database accounts are for
whole applications and if persons have different access rights, the
application handles those.

I never have seen the need to couple a MySQL database server with the
corporate dictionary. Instead we had the GRANT files for our MySQL
servers in CVS. And there was a script to automatically push the latest
GRANTs to the servers. IIRC we had about 10-20 accounts per server and
only one account (on one server) that directly matched a person.


XL

On 3/24/2011 5:13 AM, Axel Schwenke wrote:
Incorrect. In most large enterprises, the answer is YES.

That's fine if you have one person or group managing all database
servers. That is definitely NOT the case in large companies - It's not
at all unusual to have hundreds of servers managed by dozens of groups
of people. And each group determines the permissions allowed for their
server(s). But that is still determined by overall position within the
company.

Yes and no. In the real world, it is VERY common to give permissions to
people also. It's an added layer of security to sensitive data.

That's because you've never been in a large corporate environment. And
it's another example why MySQL is considered a toy database by large
companies.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

Jerry Stuckle <jstucklex (AT) attglobal (DOT) net> wrote:
You talk bullshit. Have you ever seen a productive database?

There is no contradiction here. Having a centralized dictionary for
users and permissions that are pushed to edge servers only occasionally
(meaning the edge servers have their own local dictionary) limits in no
way how many people or groups of people are managing the objects in the
dictionary.

Again I don't think *you* have ever seen a large company from inside.
Sun did it so. Oracle does it so. Change your password today and wait
up to 24 hours until it has been pushed to edge systems.


XL

On 3/24/2011 10:20 AM, Axel Schwenke wrote:
Axel, I spent 13 years with IBM, several of those working on DB2
databases. And I've been training Fortune 500 companies for another 20
years, including programming and Database Administration. I've seen a
lot more real world databases than you have.

Obviously from your updates here and other places, your ONLY experience
has been with MySQL. You really should learn what the REAL world is
like. It is NOT a toy database running on a web server.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

On 3/24/2011 12:54 PM, Michael Vilain wrote:
Not unusual at all in a corporate environment. For instance, the
corporate HQ would have a database with all employees. All employees
(and only employees) have access to some information on the database,
i.e. names, departments, internal phone numbers, etc.. Managers would
have access to additional information such as home address/phone,
salaries, etc. and be able to change that information for their
employees. Some employees could be on call 24/7, so dispatchers would
have home phone numbers (but not addresses, salaries, etc.).

Each site would have its own database containing site-specific
information. All employees would have access to some site information;
employees of that site would have access to additional information.
Managers of the site (and some employees) would have ability to
add/change information on the site.

A site with multiple buildings would have building-specific information,
similar to the site. And a department would have a database for the
department.

Now you could have multiple DBA groups involved; Corporate HQ would
obviously have one; each site could have one, and each building on a
site could have one. Departments probably wouldn't have DBA's - they
would leave it to the building DBA.

But each organization, all the way down to the department, may have
programmers writing code for things required by their organization.
These aren't necessarily fancy systems; often times it's just creating
reports from the data in a format their manager likes. But access must
be controlled.

Specific access rights are handled by groups at the organization level;
the DBA's for the system assign the desired database rights to the
group, but are not concerned about who is in the group.

With centralized administration, when an employee moves to a different
department, it's a simple matter for someone with the appropriate
authority (it could be HQ, but is often the person's old and new
managers or, even more often, an admin person assigned to that manager)
to remove that person from one set of groups and adding him/her to
another set of groups. The changes are made at the corporate level, and
are reflected down into the lower levels.

None of this is theoretical - it's the way large corporations typically
work when they have centralized administration.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

On Thu, 24 Mar 2011 09:54:02 -0700, Michael Vilain wrote:
Which is, when you think about it, entirely reasonable. Essentially,
you're really dealing with two different things: authentication and
access. Once you've established that it really is jblow at the other end
of the connection, you can THEN worry about what jblow is allowed to
look act. Which means a 5.5 style separation of authentication out to
{LDAP/PAM/some other means including internal tables} and retaining the
permissions list inside the system makes a good deal of sense.

--
94. When arresting prisoners, my guards will not allow them to stop and
grab a useless trinket of purely sentimental value.
--Peter Anspach's list of things to do as an Evil Overlord