[rt-users] Something to consider re: Gecos field?

[rt-for-chris at db.lm.com]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,

I just had a rough time trying to figure out a co-worker's problems
with RT and I thought I'd share my experience.

The user couldn't use a custom RT hack of ours that relied on the
command line interface.  I discovered that this user wasn't able to do
anything using RT's CLI, but the WebRT interface worked just fine.

If I ran 'rt --limit-queue=general --limit-status=open --summary' as
this user, I only got 1 line of output -- the summary header.  If I
ran it as myself, I got 12 lines of output.

I checked and double-checked and triple-checked all of the
user/group/queue permissions.  Everything looked fine.  I was
perplexed...

What *really* confused me is that when I gave my coworker superuser
access, I *still* only got 1 line of output.  I knew something else
had to be going on...

Finally, I decided to do a 'SELECT COUNT(*) FROM Users WHERE
Gecos="dave";'.  Guess what...  2 matches found.

It turns out that we had an RT user named 'davel' with the Unix login
field set to 'dave'.  This user didn't even have a Unix login, the
field shouldn't have even been set.  My coworker's RT name was 'dave'
and his Unix login is also 'dave'.

davel was an account that was privileged but had very little access.
The UserId was 10 for davel, while dave's UserId was 19056.  Thus, RT
was effectively using davel's rights whenever dave was using RT's CLI.

After I fixed the problem and thought about it for awhile, I wondered
why RT would allow something like this to happen...  Is this a bug or
a feature?

- -Chris

- --
Chris Tracy <chris at telerama.com>
Telerama Public Access Internet
Senior Network Engineer
http://www.telerama.com


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE+A7FcODpZMT+19JERAi9qAJ9IdV9A/Q3w6jsJ8C89v6w6rs1+FgCgsJQO
+xno2gALgtikqi5KWoNn6Eo=
=m+hj
-----END PGP SIGNATURE-----