Couple of RT questions

RT Users
1

Hi all,

I’ve finished deploying RT-1 for my company sysadmins to organise
themselves with, and it’s been a resounding success … thanks again
to you guys for this product!

A couple of questions I have:

o There doesn’t appear to be any command-line security (anyone
who has access to execute the command can manipulate the queues).
I tried chmod-ing the suid_wrapper to not allow global execution,
but then the web-server fails to execute it.

Would changing the group to the webserver’s group and allow group
execution be sufficient to secure this off, or is it vital that
the commands to be executed by anyone?

My mail daemon is exim, and so I am circumventing the suid_wrapper
as suggested by the exim instructions in the contrib directory.

I assume that the authentication is the responsibility of the UI,
is that correct?

o When using the web interface, I try to bookmark some locations
(such as the direct ticket display, or a predefined queue view).
However, if I try to access that before I authenticate, the
authenticate screen comes up, but after authentication it reverts
to the default queue view.

Requesting the URL again after successful authentication results
in the correct screen being displayed, but I’m wondering why it
doesn’t work directly ?

Thanks,
Anil

2

o There doesn’t appear to be any command-line security (anyone
who has access to execute the command can manipulate the queues).

The login name is taken as the RT userid. That means if you have a root
user in RT with full access, and you run the CLI as root, you can do
anything. It’s not a nice thing to do, though, as the transactions will
be recorded as done by “Enoch Root” or something similar.

This makes sense, people should generally not do such things while logged
in as root, and people who have root access to the box can, by theory and
by definition, do anything (s)he likes with the box. If you actually
execute rt as a user that shouldn’t have access, and you get access, there
is something seriously wrong somewhere.

I tried chmod-ing the suid_wrapper to not allow global execution,
but then the web-server fails to execute it.

chmoding the suid_wrapper is not the right thing to do.

Would changing the group to the webserver’s group and allow group
execution be sufficient to secure this off, or is it vital that
the commands to be executed by anyone?

RT1 needs to read the password from the config file, and it needs to write
and read stuff to the transaction dir. The config file should only be
readable by rt, and the transaction dir should only be read/writeable for
rt - so rt has to be run as the rt user.

I assume that the authentication is the responsibility of the UI,
is that correct?

Yes.

o When using the web interface, I try to bookmark some locations
(such as the direct ticket display, or a predefined queue view).
However, if I try to access that before I authenticate, the
authenticate screen comes up, but after authentication it reverts
to the default queue view.

Yikes. I thought we had fixed that ages ago. I guess it’s not in the
public version.

Tobias Brox
aka TobiX
+47 22 925 871

3

Tobias Brox wrote:

o There doesn’t appear to be any command-line security (anyone
who has access to execute the command can manipulate the queues).

The login name is taken as the RT userid. That means if you have a root
user in RT with full access, and you run the CLI as root, you can do
anything. It’s not a nice thing to do, though, as the transactions will
be recorded as done by “Enoch Root” or something similar.

This makes sense, people should generally not do such things while logged
in as root, and people who have root access to the box can, by theory and
by definition, do anything (s)he likes with the box. If you actually
execute rt as a user that shouldn’t have access, and you get access, there
is something seriously wrong somewhere.

Ahh, this makes sense now … it was wierd, since some of my users
have shells, and others don’t, so we were getting very confusing results
(esp. as some of the boxes we tested on had NIS activated, and others
didn’t)

Still, now that I know this, it makes it easy to work with … renamed
all RT-accounts to the same as the shell ones where applicable and
everything works well!

I tried chmod-ing the suid_wrapper to not allow global execution,
but then the web-server fails to execute it.

chmoding the suid_wrapper is not the right thing to do.

I guessed :slight_smile: Things didn’t take long to break once I did this …

o When using the web interface, I try to bookmark some locations
(such as the direct ticket display, or a predefined queue view).
However, if I try to access that before I authenticate, the
authenticate screen comes up, but after authentication it reverts
to the default queue view.

Yikes. I thought we had fixed that ages ago. I guess it’s not in the
public version.

Would it be fixed in the RT-1 CVS branch? I took the public release,
but can check it out if that fixes this problem … otherwise I’ll look
for the fix in the RT-2 branch.

Regards,
Anil

4

Would it be fixed in the RT-1 CVS branch?

Well, the logic is in lib/ui/web/auth.pm or somewhere thereabout.
FunRT should point to a RT-1 branch where this is fixed. See if you can
find something useful from the CVS log comments.

I took the public release,
but can check it out if that fixes this problem … otherwise I’ll look
for the fix in the RT-2 branch.

The web interface in RT-2 is only working halfly, and I’m not quite sure
about what have been done with authentication yet. The very most of
the RT-2 codebase is also completely new. We just found RT-1 too messy to
work with.

Tobias Brox
aka TobiX
+47 22 925 871