Eradication of Illiteracy

What talented team had defined as “the information to retrieve” has a special name: projection, and, for most relational databases, names of attributes, presented in projection, are case-insensitive.

It seems that some members of talented team think that they are smart enough to read this blog and make some conclusions about security:

API> ?,c,select user_password from dm_user where user_name=USER
user_password   
----------------
****************
(1 row affected)

API> ?,c,select * from (select user_password from dm_user where user_name=USER)
user_password   
----------------
****************
(1 row affected)

But all their attempts are doomed to failure:

API> ?,c,select USER_PASSWORD from dm_user where user_name=USER
user_password
-----------------------------------------------------------------------
AAAAEAjkr5it6wBqYfLetO/ob9j+75axyTIlb6WpnS8vLcP58ppmenSigXCm4pT1Q3nG ...

API> readquery,c,select * from (select * from dm_user where user_name=USER)
...
q0
API> next,c,q0
...
OK
API> get,c,q0,user_password
...
AAAAEAjkr5it6wBqYfLetO/ob9j+75axyTIlb6WpnS8vLcP58ppmenSigXCm4pT1Q3nGK ...

Surprise: Documentum loses data

I’m not sure whether it is a common practice, but all Documentum projects I have participated in, have the following requirement: every document, created in repository, must have unique human-readable identifier, which business users may refer in their daily activities, extra requirements could be:

  • identifiers are sequential
  • there should no holes in sequence
  • sequence starts from the beginning on every new day/week/month/year

and, depending on the requirements, implementation could be either optimistic:

private int getAnnualNextNumber(ICounter counter)
        throws DfException {
    DfException resultException = null;
    for (int i = 0; i < 10; i++) {
        try {
            synchronized (CounterService.class) {
                int lastNumber = counter.getLastNumber() + 1;
                counter.setLastNumber(lastNumber);
                counter.save();
                return lastNumber;
            }
        } catch (DfException dfe) {
            resultException = dfe;
            // neither fetch nor revert is required because DFC
            // resets object's state in
            // com.documentum.fc.client.DfSysObject#doSave
            // counter.fetch(null);
        }
    }
    throw resultException;
}

or pessimistic:

private int getAnnualNextNumber(ICounter counter)
    throws DfException {
    synchronized (CounterService.class) {
        counter.lock();
        int lastNumber = counter.getLastNumber() + 1;
        counter.setLastNumber(lastNumber);
        counter.save();
        return lastNumber;
    }
}

Interesting thing here is in case of optimistic implementation we observe that our code generates duplicates, from audit perspective it looks like CS does not receive updated value from DFC:

Q & A. XVI

I will work, maybe, in a D2 implementation project that could be released in a public site. I do not have updated information regarding D2 4.7 security holes: I need an independent point of view and you are probably the only person that has a clear understanding of what I am talking. Can you help me to understand what has not yet been fixed just in the D2 layer?

Current D2 security status: any authenticated user may gain superuser privileges 🙂