Restoring from backup -> admins lost privileges

I had to restore my MySQL database from a backup. Once I restored the RT database, the privileged users no longer had rights.

I found the below snippets to remove/add super user to my account and verify privileged users, but they are stuck in self-service mode. How do I get the rights returned back to normal?

Granting rights:
perl -I/usr/share/request-tracker4/lib/ -MRT -e’RT::LoadConfig; RT::Init;
my $u=RT::User->new($RT::SystemUser);
$u->Load(“awippler”);
($val,$msg) = $u->PrincipalObj->GrantRight(Object=> $RT::System, Right => “SuperUser”);
print “$msg\n”’

Finding privilege users: (my account is listed)
#!/usr/bin/perl
use lib “/usr/share/request-tracker4/lib”;
use RT;
use RT::Users ;
use warnings;
RT::LoadConfig(); ## Loading RT config
RT::Init(); ## Initialise RT

my $users = new RT::Users(RT_System);
$users->LimitToPrivileged;

while ( $user = $users->Next) {
print $user->Name ;
}
exit;

Andrew Wippler | Director of IT | Lancaster Baptist Church | Dr. Paul Chappell, Pastor

After a few hours of sleep, I managed to get it working with this code:

#!/usr/bin/perl
use lib “/usr/share/request-tracker4/lib”;
use RT;
use RT::Users ; ## you may not need this but what the he
use RT::User;
use warnings;
RT::LoadConfig(); ## Loading RT config
RT::Init(); ## Initialise RT

my $users = new RT::Users(RT_System);
$users->LimitToPrivileged;

while ( $user = $users->Next) {

print $user->Name ;
print " \n";
my $u = new RT::User->new($RT::SystemUser);
my ($status, $msg) = $u->Load($user->Name);
print $msg;
print " \n";

my ($vall,$msgg) = $u->SetPrivileged(1);
print $msgg;
print " \n";
}
exit;

Old tickets will not allow me to re-assign the owner; however, it works on newly created tickets.

Andrew Wippler | Director of IT | Lancaster Baptist Church | Dr. Paul Chappell, PastorFrom: rt-users rt-users-bounces@lists.bestpractical.com on behalf of rt-users-request@lists.bestpractical.com rt-users-request@lists.bestpractical.com
Sent: Friday, February 13, 2015 4:46 AM
To: rt-users@lists.bestpractical.com
Subject: rt-users Digest, Vol 131, Issue 13

Send rt-users mailing list submissions to
rt-users@lists.bestpractical.com

To subscribe or unsubscribe via the World Wide Web, visit
The rt-users Archives
or, via email, send a message with subject or body ‘help’ to
rt-users-request@lists.bestpractical.com

You can reach the person managing the list at
rt-users-owner@lists.bestpractical.com

When replying, please edit your Subject line so it is more specific
than “Re: Contents of rt-users digest…”

Today’s Topics:

  1. Prevent users from adding CC’s and AdminCC’s to tickets
    (Cena, Stephen (ext. 300))
  2. Prevent users from making Comments on tickets
    (Cena, Stephen (ext. 300))
  3. fail2ban With RT (Matt Brennan)
  4. Re: Prevent users from making Comments on tickets (Alex Peters)
  5. Re: Prevent users from adding CC’s and AdminCC’s to tickets
    (Alex Peters)
  6. Re: Prevent users from making Comments on tickets
    (Daniel Schwager)
  7. Restoring from backup → admins lost privileges (Andrew Wippler)
  8. unsubscribe (Steve Hanselman)
  9. Re: Prevent users from making Comments on tickets (Alex Peters)

Message: 1
Date: Thu, 12 Feb 2015 17:26:33 +0000
From: “Cena, Stephen (ext. 300)” SJC@qvii.com
To: “rt-users@lists.bestpractical.com
rt-users@lists.bestpractical.com
Subject: [rt-users] Prevent users from adding CC’s and AdminCC’s to
tickets
Message-ID:
0CE56AE307C0BC4B950BF05F3759DF4357D162D9@MailStore2010.ogp.qvii.com
Content-Type: text/plain; charset=“us-ascii”

What permissions do I need to remove/enable to prevent users from modifying the CC/AdminCC lists (more specifically the AdminCC list). The audit trail of when people being added & removed is helpful, but I’d like to prevent it outright.

Stephen J. Cena
Supervisor/Systems Administrator - MIS/IT Dept
Quality Vision International
850 Hudson Ave
Rochester,NY 14620
Phone: 585-544-0450 x300


Please report email problems to: postmaster@qvii.commailto:postmaster@qvii.com

QVII MIS/IT Dept - We do what we must because we can.
“Thank you for helping us help you help us all.”


-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20150212/fc0d4892/attachment-0001.html

Message: 2
Date: Thu, 12 Feb 2015 17:06:48 +0000
From: “Cena, Stephen (ext. 300)” SJC@qvii.com
To: “rt-users@lists.bestpractical.com
rt-users@lists.bestpractical.com
Subject: [rt-users] Prevent users from making Comments on tickets
Message-ID:
0CE56AE307C0BC4B950BF05F3759DF4357D162B2@MailStore2010.ogp.qvii.com
Content-Type: text/plain; charset=“us-ascii”

I’m in the process of locking down end-user permissions in our RT install. We want it set up so that users can only do Reply, and Admins can use Comment and Reply. At present, my “end user” can’t see a Comment in a ticket, or an attachment made with a Comment. However, if the user emails the Comment address or uses the Comment in the Action drop-down in the ticket the entry gets made. The proper visibility of the resulting Comment is correct. AFAIK, there are no global permissions for anything (I’m doing it al at the queue level for each queue).

Everyone, Privileged, Unprivileged all have no permissions
End User perms for queue: CreateTicket, SeeQueue
Requestor perms for queue: ReplyToTicket, SeeCustomField, SeeQueue, ShowTicket, ModifyCustomField, ModifyTicket

Did I overlook something?

Stephen J. Cena
Supervisor/Systems Administrator - MIS/IT Dept
Quality Vision International
850 Hudson Ave
Rochester,NY 14620
Phone: 585-544-0450 x300


Please report email problems to: postmaster@qvii.commailto:postmaster@qvii.com

QVII MIS/IT Dept - We do what we must because we can.
“Thank you for helping us help you help us all.”


-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20150212/f866b1db/attachment-0001.html

Message: 3
Date: Thu, 12 Feb 2015 16:59:08 -0500
From: Matt Brennan brennanma@gmail.com
To: rt-users@lists.bestpractical.com
Subject: [rt-users] fail2ban With RT
Message-ID:
CACLBzupjPx89CoFqz_k9uW-QGBSVtmdJOoCkYdj-Cbdm3kfODA@mail.gmail.com
Content-Type: text/plain; charset=“utf-8”

Good Day,

I am soon going to be exposing my RT instance on a public IP. It
currently requires VPN access, but users have asked for this to be changed.
As a result, I am trying to implement fail2ban, but am running into some
issues. I’m wondering if anyone else has successfully done this.

Running fail2ban-regexp against the Apache error log and the fail2ban
filter file show that there are matches, however running fail2ban in debug
mode does not show that it’s matching at run time.

The relevant configs are below. Any help appreciated.

Thanks,
Matt

jail.conf:
[rt-iptables]
enabled = true
filter = rtauth
action = iptables-allports[name=RT, protocol=all]
logpath = /var/log/apache2/error.log
maxretry = 4
findtime = 21600
bantime = 86400

filter.d/rtauth.conf:
[INCLUDES]
before = apache-common.conf

[Definition]
failregex = [.] [[^]]+] [error]: FAILED LOGIN for . from
(.*)$
ignoreregex =
-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20150212/6f1384b1/attachment-0001.html

Message: 4
Date: Fri, 13 Feb 2015 11:10:37 +1100
From: Alex Peters alex@peters.net
To: “Cena, Stephen (ext. 300)” SJC@qvii.com
Cc: “rt-users@lists.bestpractical.com
rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Prevent users from making Comments on tickets
Message-ID:
CAFdkmpumX12XDdNOXwjhrSwU4Wx1XUGqyaHppjkF3MC6Tbv97A@mail.gmail.com
Content-Type: text/plain; charset=“utf-8”

I believe that a user will unconditionally have commenting ability if they
also have the ModifyTicket right, regardless of the state of their
CommentOnTicket right.

You might be able to swap out ModifyTicket and use some finer-grained
rights in its place, depending on what modifications end users actually
need to make.

I’m in the process of locking down end-user permissions in our RT
install. We want it set up so that users can only do Reply, and Admins can
use Comment and Reply. At present, my “end user” can’t see a Comment in a
ticket, or an attachment made with a Comment. However, if the user emails
the Comment address or uses the Comment in the Action drop-down in the
ticket the entry gets made. The proper visibility of the resulting Comment
is correct. AFAIK, there are no global permissions for anything (I’m doing
it al at the queue level for each queue).

Everyone, Privileged, Unprivileged all have no permissions
End User perms for queue: CreateTicket, SeeQueue
Requestor perms for queue: ReplyToTicket, SeeCustomField, SeeQueue,
ShowTicket, ModifyCustomField, ModifyTicket

Did I overlook something?

Stephen J. Cena
Supervisor/Systems Administrator - MIS/IT Dept
Quality Vision International
850 Hudson Ave
Rochester,NY 14620
Phone: 585-544-0450 x300


Please report email problems to: postmaster@qvii.com

QVII MIS/IT Dept - We do what we must because we can.
“Thank you for helping us help you help us all.”


-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20150213/944c01c8/attachment-0001.html

Message: 5
Date: Fri, 13 Feb 2015 11:34:08 +1100
From: Alex Peters alex@peters.net
To: “Cena, Stephen (ext. 300)” SJC@qvii.com
Cc: “rt-users@lists.bestpractical.com
rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Prevent users from adding CC’s and AdminCC’s
to tickets
Message-ID:
CAFdkmpu=2kCxDsc+hP7+iVAH_NFM7qBr3M02men_uNAzh5SE7g@mail.gmail.com
Content-Type: text/plain; charset=“utf-8”

From the v4.2.7 code, I’m interpreting these rules:

  1. Add/remove anyone if the user has the ModifyTicket right.
  2. Only add/remove self as AdminCc if the user has the WatchAsAdminCc
    right.
  3. Only add/remove self as Cc/Requestor if the user has the Watch right.

The logic is probably the same for all other recent versions of RT, but if
in doubt, take a look at the _HasModifyWatcherRight method in
lib/RT/Ticket.pm.

What permissions do I need to remove/enable to prevent users from
modifying the CC/AdminCC lists (more specifically the AdminCC list). The
audit trail of when people being added & removed is helpful, but I’d like
to prevent it outright.

Stephen J. Cena
Supervisor/Systems Administrator - MIS/IT Dept
Quality Vision International
850 Hudson Ave
Rochester,NY 14620
Phone: 585-544-0450 x300


Please report email problems to: postmaster@qvii.com

QVII MIS/IT Dept - We do what we must because we can.
“Thank you for helping us help you help us all.”


-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20150213/1e8bd7cc/attachment-0001.html

Message: 6
Date: Fri, 13 Feb 2015 06:52:01 +0000
From: Daniel Schwager Daniel.Schwager@dtnet.de
To: ‘Alex Peters’ alex@peters.net, “‘Cena, Stephen (ext. 300)’”
SJC@qvii.com
Cc: “‘rt-users@lists.bestpractical.com’”
rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Prevent users from making Comments on tickets
Message-ID:
5C4B841CCF894A4CBD8B13E25E2A575F20DCB6B9@exchange2.dtnet.de
Content-Type: text/plain; charset=“utf-8”

Hi,

You might be able to swap out ModifyTicket and use some
finer-grained rights in its place, depending on what modifications
end users actually need to make.

what are the equivalent (separate) rights for ModifyTicket?

regards
Danny

From: rt-users [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Alex Peters
Sent: Friday, February 13, 2015 1:11 AM
To: Cena, Stephen (ext. 300)
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Prevent users from making Comments on tickets

I believe that a user will unconditionally have commenting ability if they also have the ModifyTicket right, regardless of the state of their CommentOnTicket right.

You might be able to swap out ModifyTicket and use some finer-grained rights in its place, depending on what modifications end users actually need to make.

I’m in the process of locking down end-user permissions in our RT install. We want it set up so that users can only do Reply, and Admins can use Comment and Reply. At present, my “end user” can’t see a Comment in a ticket, or an attachment made with a Comment. However, if the user emails the Comment address or uses the Comment in the Action drop-down in the ticket the entry gets made. The proper visibility of the resulting Comment is correct. AFAIK, there are no global permissions for anything (I’m doing it al at the queue level for each queue).

-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20150213/eb94b235/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed…
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2279 bytes
Desc: not available
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20150213/eb94b235/attachment-0001.bin

Message: 7
Date: Fri, 13 Feb 2015 07:04:03 +0000
From: Andrew Wippler Andrew.Wippler@lancasterbaptist.org
To: “rt-users@lists.bestpractical.com
rt-users@lists.bestpractical.com
Subject: [rt-users] Restoring from backup → admins lost privileges
Message-ID: 1456d5bc867a425cae984e170f8a2531@zerah
Content-Type: text/plain; charset=“us-ascii”

I had to restore my MySQL database from a backup. Once I restored the RT database, the privileged users no longer had rights.

I found the below snippets to remove/add super user to my account and verify privileged users, but they are stuck in self-service mode. How do I get the rights returned back to normal?

Granting rights:
perl -I/usr/share/request-tracker4/lib/ -MRT -e’RT::LoadConfig; RT::Init;
my $u=RT::User->new($RT::SystemUser);
$u->Load(“awippler”);
($val,$msg) = $u->PrincipalObj->GrantRight(Object=> $RT::System, Right => “SuperUser”);
print “$msg\n”’

Finding privilege users: (my account is listed)
#!/usr/bin/perl
use lib “/usr/share/request-tracker4/lib”;
use RT;
use RT::Users ;
use warnings;
RT::LoadConfig(); ## Loading RT config
RT::Init(); ## Initialise RT

my $users = new RT::Users(RT_System);
$users->LimitToPrivileged;

while ( $user = $users->Next) {
print $user->Name ;
}
exit;

Andrew Wippler | Director of IT | Lancaster Baptist Church | Dr. Paul Chappell, Pastor
-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20150213/a7348872/attachment-0001.html

Message: 8
Date: Fri, 13 Feb 2015 11:42:16 -0000
From: “Steve Hanselman” steveh@brendata.co.uk
To: rt-users@lists.bestpractical.com
Subject: [rt-users] unsubscribe
Message-ID:
6B8895CA39846F4DB78FAE7979D9D77E01064171@prodntsc2.brendata
Content-Type: text/plain; charset=“us-ascii”

-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20150213/33d3d343/attachment-0001.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: SpamAssassinReport.txt
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20150213/33d3d343/attachment-0001.txt

Message: 9
Date: Fri, 13 Feb 2015 23:46:20 +1100
From: Alex Peters alex@peters.net
To: Daniel Schwager Daniel.Schwager@dtnet.de
Cc: “rt-users@lists.bestpractical.com
rt-users@lists.bestpractical.com, “Cena, Stephen (ext. 300)”
SJC@qvii.com
Subject: Re: [rt-users] Prevent users from making Comments on tickets
Message-ID:
CAFdkmpvrPPw08PjKNurubn_c=PK2fj7py2fkHYDo8TBrQ=xvUg@mail.gmail.com
Content-Type: text/plain; charset=“utf-8”

ModifyTicket is not a strict combination of other rights. I believe that
without ModifyTicket, you must experiment to determine which rights provide
the correct behaviour for your needs.

Hi,

You might be able to swap out ModifyTicket and use some

finer-grained rights in its place, depending on what modifications

end users actually need to make.

what are the equivalent (separate) rights for ModifyTicket?

regards

Danny

From*:* rt-users [mailto:rt-users-bounces@lists.bestpractical.com] *On
Behalf Of *Alex Peters
Sent: Friday, February 13, 2015 1:11 AM
To: Cena, Stephen (ext. 300)
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Prevent users from making Comments on tickets

I believe that a user will unconditionally have commenting ability if they
also have the ModifyTicket right, regardless of the state of their
CommentOnTicket right.

You might be able to swap out ModifyTicket and use some finer-grained
rights in its place, depending on what modifications end users actually
need to make.

I’m in the process of locking down end-user permissions in our RT install.
We want it set up so that users can only do Reply, and Admins can use
Comment and Reply. At present, my “end user” can’t see a Comment in a
ticket, or an attachment made with a Comment. However, if the user emails
the Comment address or uses the Comment in the Action drop-down in the
ticket the entry gets made. The proper visibility of the resulting Comment
is correct. AFAIK, there are no global permissions for anything (I’m doing
it al at the queue level for each queue).

-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.bestpractical.com/pipermail/rt-users/attachments/20150213/c0c53be3/attachment.html

Subject: Digest Footer

rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

End of rt-users Digest, Vol 131, Issue 13

This implies that something is wrong with you backups.

ChrisAm 13.02.2015 um 08:04 schrieb Andrew Wippler:

I had to restore my MySQL database from a backup. Once I restored the RT
database, the privileged users no longer had rights.

I found the below snippets to remove/add super user to my account and
verify privileged users, but they are stuck in self-service mode. How do
I get the rights returned back to normal?

Granting rights:
perl -I/usr/share/request-tracker4/lib/ -MRT -e’RT::LoadConfig; RT::Init;
my $u=RT::User->new($RT::SystemUser);
$u->Load(“awippler”);
($val,$msg) = $u->PrincipalObj->GrantRight(Object=> $RT::System, Right
=> “SuperUser”);
print “$msg\n”’

Finding privilege users: (my account is listed)
#!/usr/bin/perl
use lib “/usr/share/request-tracker4/lib”;
use RT;
use RT::Users ;
use warnings;
RT::LoadConfig(); ## Loading RT config
RT::Init(); ## Initialise RT

my $users = new RT::Users(RT_System);
$users->LimitToPrivileged;

while ( $user = $users->Next) {
print $user->Name ;
}
exit;

Andrew Wippler | Director of IT | Lancaster Baptist Church | Dr. Paul
Chappell, Pastor

After a few hours of sleep, I managed to get it working with this code:
[snip]

For posterity, this is not the solution you want. If your users did
not come across as Privileged, there are likely a huge slew of other
hidden problems. Attempting to paper over it via this method is
dangerous – you just made every email address that has ever sent your
RT spam into a Privileged user.

Fix your database backups.

  • Alex