permission problems with script run via crondargs -m

[Robert Moskowitz]

A little background first.

This is for Fedora 32 workstation which does not come with a default MTA 
and thus there is a slight challenge (ahem) getting CRON's output into 
the local mailstore.  I don't want to install an MTA (leave why for 
Fedora users list discuss) and "procmail -f cron" leaves out a DATE 
header.  So I wrote my own little script that I put in /usr/local/mycron 
that takes the output from cron and appends the proper content to 
/var/spool/mail/$USER.

Works fine for my personal crontab, but has selinux problems for 
logwatch running as root (and probably any other cron task running as root).

So I first got told by selinux troubleshooting that I needed:

ausearch -c 'mycron' --raw | audit2allow -M my-mycron
semodule -X 300 -i my-mycron.pp

Which I did.  Then after this night's run of logwatch, I see that I have 
the selinux troubleshoot icon, but when I look, it is empty? So I grep 
messages for logwatch, then grep the time it was running and found the 
following:

May 11 03:43:19 lx140e setroubleshoot[121345]: SELinux is preventing 
mycron from add_name
access on the directory root. For complete SELinux messages run: sealert 
-l 8eb93a73-c7ff-
42ec-bee1-594d77540808
May 11 03:43:19 lx140e python3[121345]: SELinux is preventing mycron 
from add_name access
on the directory root.#012#012*****  Plugin catchall (100. confidence) 
suggests   ********
******************#012#012If you believe that mycron should be allowed 
add_name access on
the root directory by default.#012Then you should report this as a 
bug.#012You can generat
e a local policy module to allow this access.#012Do#012allow this access 
for now by execut
ing:#012# ausearch -c 'mycron' --raw | audit2allow -M my-mycron#012# 
semodule -X 300 -i my
-mycron.pp#012
May 11 03:43:23 lx140e systemd[1]: 
dbus-:[e-mail]:
  Succeeded.

So it looks like now I am told to run:

ausearch -c 'mycron' --raw | audit2allow -M my-mycron
semodule -X 300 -i my-mycron.pp

Wait, that is the same I ran earlier?  And why did I have to grep 
messages to find these?

Now I did update mycron in between.  Will I have to run this every time 
I update mycron?  How do I make it permanent?  Also right now there is 
no /var/spool/mail/root mbox file.

thanks

[Lukas Vrabec]

On 5/11/20 2:23 PM, Robert Moskowitz wrote:
>  A little background first.
>  
>  This is for Fedora 32 workstation which does not come with a default MTA
>  and thus there is a slight challenge (ahem) getting CRON's output into
>  the local mailstore.  I don't want to install an MTA (leave why for
>  Fedora users list discuss) and "procmail -f cron" leaves out a DATE
>  header.  So I wrote my own little script that I put in /usr/local/mycron
>  that takes the output from cron and appends the proper content to
>  /var/spool/mail/$USER.
>  
>  Works fine for my personal crontab, but has selinux problems for
>  logwatch running as root (and probably any other cron task running as
>  root).
>  
>  So I first got told by selinux troubleshooting that I needed:
>  
>  ausearch -c 'mycron' --raw | audit2allow -M my-mycron
>  semodule -X 300 -i my-mycron.pp
>  
>  Which I did.  Then after this night's run of logwatch, I see that I have
>  the selinux troubleshoot icon, but when I look, it is empty? So I grep
>  messages for logwatch, then grep the time it was running and found the
>  following:
>  
>  May 11 03:43:19 lx140e setroubleshoot[121345]: SELinux is preventing
>  mycron from add_name
>  access on the directory root. For complete SELinux messages run: sealert
>  -l 8eb93a73-c7ff-
>  42ec-bee1-594d77540808
>  May 11 03:43:19 lx140e python3[121345]: SELinux is preventing mycron
>  from add_name access
>  on the directory root.#012#012*****  Plugin catchall (100. confidence)
>  suggests   ********
>  ******************#012#012If you believe that mycron should be allowed
>  add_name access on
>  the root directory by default.#012Then you should report this as a
>  bug.#012You can generat
>  e a local policy module to allow this access.#012Do#012allow this access
>  for now by execut
>  ing:#012# ausearch -c 'mycron' --raw | audit2allow -M my-mycron#012#
>  semodule -X 300 -i my
>  -mycron.pp#012
>  May 11 03:43:23 lx140e systemd[1]:
>  dbus-:[e-mail]:
>   Succeeded.
>  
>  So it looks like now I am told to run:
>  
>  ausearch -c 'mycron' --raw | audit2allow -M my-mycron
>  semodule -X 300 -i my-mycron.pp
>  
>  Wait, that is the same I ran earlier?  And why did I have to grep
>  messages to find these?
>   
Hi,

Could you please share output of this command:

# sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808

Then we can help you,
Thanks,
Lukas.

>  Now I did update mycron in between.  Will I have to run this every
> time
>  I update mycron?  How do I make it permanent?  Also right now there is
>  no /var/spool/mail/root mbox file.
>  
>  thanks
>  _______________________________________________
>  selinux mailing list -- selinux(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>   

-- 
Lukas Vrabec
SELinux Evangelist,
Senior Software Engineer, Security Technologies
Red Hat, Inc.

[Robert Moskowitz]

On 5/11/20 9:04 AM, Lukas Vrabec wrote:
>  On 5/11/20 2:23 PM, Robert Moskowitz wrote:
> > A little background first.
> >
> > This is for Fedora 32 workstation which does not come with a default MTA
> > and thus there is a slight challenge (ahem) getting CRON's output into
> > the local mailstore.  I don't want to install an MTA (leave why for
> > Fedora users list discuss) and "procmail -f cron" leaves out a DATE
> > header.  So I wrote my own little script that I put in /usr/local/mycron
> > that takes the output from cron and appends the proper content to
> > /var/spool/mail/$USER.
> >
> > Works fine for my personal crontab, but has selinux problems for
> > logwatch running as root (and probably any other cron task running as
> > root).
> >
> > So I first got told by selinux troubleshooting that I needed:
> >
> > ausearch -c 'mycron' --raw | audit2allow -M my-mycron
> > semodule -X 300 -i my-mycron.pp
> >
> > Which I did.  Then after this night's run of logwatch, I see that I have
> > the selinux troubleshoot icon, but when I look, it is empty? So I grep
> > messages for logwatch, then grep the time it was running and found the
> > following:
> >
> > May 11 03:43:19 lx140e setroubleshoot[121345]: SELinux is preventing
> > mycron from add_name
> > access on the directory root. For complete SELinux messages run: sealert
> > -l 8eb93a73-c7ff-
> > 42ec-bee1-594d77540808
> > May 11 03:43:19 lx140e python3[121345]: SELinux is preventing mycron
> > from add_name access
> > on the directory root.#012#012*****  Plugin catchall (100. confidence)
> > suggests   ********
> > ******************#012#012If you believe that mycron should be allowed
> > add_name access on
> > the root directory by default.#012Then you should report this as a
> > bug.#012You can generat
> > e a local policy module to allow this access.#012Do#012allow this access
> > for now by execut
> > ing:#012# ausearch -c 'mycron' --raw | audit2allow -M my-mycron#012#
> > semodule -X 300 -i my
> > -mycron.pp#012
> > May 11 03:43:23 lx140e systemd[1]:
> > dbus-:[e-mail]:
> >   Succeeded.
> >
> > So it looks like now I am told to run:
> >
> > ausearch -c 'mycron' --raw | audit2allow -M my-mycron
> > semodule -X 300 -i my-mycron.pp
> >
> > Wait, that is the same I ran earlier?  And why did I have to grep
> > messages to find these?
> >
>  Hi,
>
>  Could you please share output of this command:
>
>  # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808 
# sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
Error
query_alerts error (1003): id (8eb93a73-c7ff-42ec-bee1-594d77540808) not 
found

And from the first selinux alert:

# sealert -l d05d8373-fae7-447e-b45a-74940959809e
Error
query_alerts error (1003): id (d05d8373-fae7-447e-b45a-74940959809e) not 
found

I viewed the alerts with the SELinux troubleshooter, but I did NOT tell 
it to delete the alert :(

>  Then we can help you,
>  Thanks,
>  Lukas.
>
> > Now I did update mycron in between.  Will I have to run this every time
> > I update mycron?  How do I make it permanent?  Also right now there is
> > no /var/spool/mail/root mbox file.
> >
> > thanks

[Lukas Vrabec]

On 5/11/20 3:19 PM, Robert Moskowitz wrote:
>  
>  
>  On 5/11/20 9:04 AM, Lukas Vrabec wrote:
> > On 5/11/20 2:23 PM, Robert Moskowitz wrote:
> >> A little background first.
> >>
> >> This is for Fedora 32 workstation which does not come with a default MTA
> >> and thus there is a slight challenge (ahem) getting CRON's output into
> >> the local mailstore.  I don't want to install an MTA (leave why for
> >> Fedora users list discuss) and "procmail -f cron" leaves out a DATE
> >> header.  So I wrote my own little script that I put in /usr/local/mycron
> >> that takes the output from cron and appends the proper content to
> >> /var/spool/mail/$USER.
> >>
> >> Works fine for my personal crontab, but has selinux problems for
> >> logwatch running as root (and probably any other cron task running as
> >> root).
> >>
> >> So I first got told by selinux troubleshooting that I needed:
> >>
> >> ausearch -c 'mycron' --raw | audit2allow -M my-mycron
> >> semodule -X 300 -i my-mycron.pp
> >>
> >> Which I did.  Then after this night's run of logwatch, I see that I have
> >> the selinux troubleshoot icon, but when I look, it is empty? So I grep
> >> messages for logwatch, then grep the time it was running and found the
> >> following:
> >>
> >> May 11 03:43:19 lx140e setroubleshoot[121345]: SELinux is preventing
> >> mycron from add_name
> >> access on the directory root. For complete SELinux messages run: sealert
> >> -l 8eb93a73-c7ff-
> >> 42ec-bee1-594d77540808
> >> May 11 03:43:19 lx140e python3[121345]: SELinux is preventing mycron
> >> from add_name access
> >> on the directory root.#012#012*****  Plugin catchall (100. confidence)
> >> suggests   ********
> >> ******************#012#012If you believe that mycron should be allowed
> >> add_name access on
> >> the root directory by default.#012Then you should report this as a
> >> bug.#012You can generat
> >> e a local policy module to allow this access.#012Do#012allow this access
> >> for now by execut
> >> ing:#012# ausearch -c 'mycron' --raw | audit2allow -M my-mycron#012#
> >> semodule -X 300 -i my
> >> -mycron.pp#012
> >> May 11 03:43:23 lx140e systemd[1]:
> >> dbus-:[e-mail]:
> >>   Succeeded.
> >>
> >> So it looks like now I am told to run:
> >>
> >> ausearch -c 'mycron' --raw | audit2allow -M my-mycron
> >> semodule -X 300 -i my-mycron.pp
> >>
> >> Wait, that is the same I ran earlier?  And why did I have to grep
> >> messages to find these?
> >>
> > Hi,
> >
> > Could you please share output of this command:
> >
> > # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
>  
>  # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
>  Error
>  query_alerts error (1003): id (8eb93a73-c7ff-42ec-bee1-594d77540808) not
>  found
>  
>  And from the first selinux alert:
>  
>  # sealert -l d05d8373-fae7-447e-b45a-74940959809e
>  Error
>  query_alerts error (1003): id (d05d8373-fae7-447e-b45a-74940959809e) not
>  found
>  
>  I viewed the alerts with the SELinux troubleshooter, but I did NOT tell
>  it to delete the alert :(
>   
No problem, are you able to reproduce it? If yes, please do and then attach:

# ausearch -m AVC,USER_AVC -ts today

Thanks,
Lukas.

> > Then we can help you,
> > Thanks,
> > Lukas.
> >
> >> Now I did update mycron in between.  Will I have to run this every time
> >> I update mycron?  How do I make it permanent?  Also right now there is
> >> no /var/spool/mail/root mbox file.
> >>
> >> thanks
>   

-- 
Lukas Vrabec
SELinux Evangelist,
Senior Software Engineer, Security Technologies
Red Hat, Inc.

[Robert Moskowitz]

On 5/11/20 9:40 AM, Lukas Vrabec wrote:
>  On 5/11/20 3:19 PM, Robert Moskowitz wrote:
> >
> > On 5/11/20 9:04 AM, Lukas Vrabec wrote:
> >> On 5/11/20 2:23 PM, Robert Moskowitz wrote:
> >>> A little background first.
> >>>
> >>> This is for Fedora 32 workstation which does not come with a default MTA
> >>> and thus there is a slight challenge (ahem) getting CRON's output into
> >>> the local mailstore.  I don't want to install an MTA (leave why for
> >>> Fedora users list discuss) and "procmail -f cron" leaves out a
> DATE
> >>> header.  So I wrote my own little script that I put in /usr/local/mycron
> >>> that takes the output from cron and appends the proper content to
> >>> /var/spool/mail/$USER.
> >>>
> >>> Works fine for my personal crontab, but has selinux problems for
> >>> logwatch running as root (and probably any other cron task running as
> >>> root).
> >>>
> >>> So I first got told by selinux troubleshooting that I needed:
> >>>
> >>> ausearch -c 'mycron' --raw | audit2allow -M my-mycron
> >>> semodule -X 300 -i my-mycron.pp
> >>>
> >>> Which I did.  Then after this night's run of logwatch, I see that I have
> >>> the selinux troubleshoot icon, but when I look, it is empty? So I grep
> >>> messages for logwatch, then grep the time it was running and found the
> >>> following:
> >>>
> >>> May 11 03:43:19 lx140e setroubleshoot[121345]: SELinux is preventing
> >>> mycron from add_name
> >>> access on the directory root. For complete SELinux messages run: sealert
> >>> -l 8eb93a73-c7ff-
> >>> 42ec-bee1-594d77540808
> >>> May 11 03:43:19 lx140e python3[121345]: SELinux is preventing mycron
> >>> from add_name access
> >>> on the directory root.#012#012*****  Plugin catchall (100. confidence)
> >>> suggests   ********
> >>> ******************#012#012If you believe that mycron should be allowed
> >>> add_name access on
> >>> the root directory by default.#012Then you should report this as a
> >>> bug.#012You can generat
> >>> e a local policy module to allow this access.#012Do#012allow this access
> >>> for now by execut
> >>> ing:#012# ausearch -c 'mycron' --raw | audit2allow -M my-mycron#012#
> >>> semodule -X 300 -i my
> >>> -mycron.pp#012
> >>> May 11 03:43:23 lx140e systemd[1]:
> >>> dbus-:[e-mail]:
> >>>    Succeeded.
> >>>
> >>> So it looks like now I am told to run:
> >>>
> >>> ausearch -c 'mycron' --raw | audit2allow -M my-mycron
> >>> semodule -X 300 -i my-mycron.pp
> >>>
> >>> Wait, that is the same I ran earlier?  And why did I have to grep
> >>> messages to find these?
> >>>
> >> Hi,
> >>
> >> Could you please share output of this command:
> >>
> >> # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
> > # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
> > Error
> > query_alerts error (1003): id (8eb93a73-c7ff-42ec-bee1-594d77540808) not
> > found
> >
> > And from the first selinux alert:
> >
> > # sealert -l d05d8373-fae7-447e-b45a-74940959809e
> > Error
> > query_alerts error (1003): id (d05d8373-fae7-447e-b45a-74940959809e) not
> > found
> >
> > I viewed the alerts with the SELinux troubleshooter, but I did NOT tell
> > it to delete the alert :(
> >
>  No problem, are you able to reproduce it? If yes, please do and then attach:
>
>  # ausearch -m AVC,USER_AVC -ts today 

In /etc/crontab I put:

30 * * * * root /bin/ls

And it ran fine creating /var/spool/mail/root with the proper content 
via mycron script.

So I will have to wait until 3am tonight to see what logwatch does this 
time.

Oh, and here is what ausearch reports:

# ausearch -m AVC,USER_AVC -ts today
----
time->Mon May 11 03:43:06 2020
type=AVC msg=audit(1589182986.533:3571): avc:  denied  { add_name } for  
pid=121331 comm="mycron" name="root" 
scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir permissive=0



>  Thanks,
>  Lukas.
>
> >> Then we can help you,
> >> Thanks,
> >> Lukas.
> >>
> >>> Now I did update mycron in between.  Will I have to run this every time
> >>> I update mycron?  How do I make it permanent?  Also right now there is
> >>> no /var/spool/mail/root mbox file.
> >>>
> >>> thanks
> >

[Robert Moskowitz]

Lukas,

Failed again last night see the end of this message.

On 5/11/20 9:40 AM, Lukas Vrabec wrote:
>  On 5/11/20 3:19 PM, Robert Moskowitz wrote:
> >
> > On 5/11/20 9:04 AM, Lukas Vrabec wrote:
> >> On 5/11/20 2:23 PM, Robert Moskowitz wrote:
> >>> A little background first.
> >>>
> >>> This is for Fedora 32 workstation which does not come with a default MTA
> >>> and thus there is a slight challenge (ahem) getting CRON's output into
> >>> the local mailstore.  I don't want to install an MTA (leave why for
> >>> Fedora users list discuss) and "procmail -f cron" leaves out a
> DATE
> >>> header.  So I wrote my own little script that I put in /usr/local/mycron
> >>> that takes the output from cron and appends the proper content to
> >>> /var/spool/mail/$USER.
> >>>
> >>> Works fine for my personal crontab, but has selinux problems for
> >>> logwatch running as root (and probably any other cron task running as
> >>> root).
> >>>
> >>> So I first got told by selinux troubleshooting that I needed:
> >>>
> >>> ausearch -c 'mycron' --raw | audit2allow -M my-mycron
> >>> semodule -X 300 -i my-mycron.pp
> >>>
> >>> Which I did.  Then after this night's run of logwatch, I see that I have
> >>> the selinux troubleshoot icon, but when I look, it is empty? So I grep
> >>> messages for logwatch, then grep the time it was running and found the
> >>> following:
> >>>
> >>> May 11 03:43:19 lx140e setroubleshoot[121345]: SELinux is preventing
> >>> mycron from add_name
> >>> access on the directory root. For complete SELinux messages run: sealert
> >>> -l 8eb93a73-c7ff-
> >>> 42ec-bee1-594d77540808
> >>> May 11 03:43:19 lx140e python3[121345]: SELinux is preventing mycron
> >>> from add_name access
> >>> on the directory root.#012#012*****  Plugin catchall (100. confidence)
> >>> suggests   ********
> >>> ******************#012#012If you believe that mycron should be allowed
> >>> add_name access on
> >>> the root directory by default.#012Then you should report this as a
> >>> bug.#012You can generat
> >>> e a local policy module to allow this access.#012Do#012allow this access
> >>> for now by execut
> >>> ing:#012# ausearch -c 'mycron' --raw | audit2allow -M my-mycron#012#
> >>> semodule -X 300 -i my
> >>> -mycron.pp#012
> >>> May 11 03:43:23 lx140e systemd[1]:
> >>> dbus-:[e-mail]:
> >>>    Succeeded.
> >>>
> >>> So it looks like now I am told to run:
> >>>
> >>> ausearch -c 'mycron' --raw | audit2allow -M my-mycron
> >>> semodule -X 300 -i my-mycron.pp
> >>>
> >>> Wait, that is the same I ran earlier?  And why did I have to grep
> >>> messages to find these?
> >>>
> >> Hi,
> >>
> >> Could you please share output of this command:
> >>
> >> # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
> > # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
> > Error
> > query_alerts error (1003): id (8eb93a73-c7ff-42ec-bee1-594d77540808) not
> > found
> >
> > And from the first selinux alert:
> >
> > # sealert -l d05d8373-fae7-447e-b45a-74940959809e
> > Error
> > query_alerts error (1003): id (d05d8373-fae7-447e-b45a-74940959809e) not
> > found
> >
> > I viewed the alerts with the SELinux troubleshooter, but I did NOT tell
> > it to delete the alert :(
> >
>  No problem, are you able to reproduce it? If yes, please do and then attach:
>
>  # ausearch -m AVC,USER_AVC -ts today 
# ausearch -m AVC,USER_AVC -ts today
----
time->Tue May 12 03:22:06 2020
type=AVC msg=audit(1589268126.630:3796): avc:  denied  { add_name } for  
pid=142359 comm="mycron" name="root" 
scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir permissive=0

May 12 03:22:06 lx140e audit[142359]: AVC avc:  denied  { add_name } 
for  pid=142359 comm="mycron" name="root" 
scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir permissive=0
May 12 03:22:09 lx140e systemd[1]: Started 
dbus-:[e-mail].
May 12 03:22:09 lx140e audit[1]: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='unit=dbus-:1.1-org.fedoraproject.Setroubleshootd@20 comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 12 03:22:13 lx140e systemd[1]: Started 
dbus-:[e-mail].
May 12 03:22:13 lx140e audit[1]: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='unit=dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? 
terminal=? res=success'
May 12 03:22:19 lx140e setroubleshoot[142374]: SELinux is preventing 
mycron from add_name access on the directory root. For complete SELinux 
messages run: sealert -l 9fd5890f-400b-4ae0-8a98-43575ac4913a
May 12 03:22:19 lx140e python3[142374]: SELinux is preventing mycron 
from add_name access on the directory root.#012#012*****  Plugin 
catchall (100. confidence) suggests **************************#012#012If 
you believe that mycron should be allowed add_name access on the root 
directory by default.#012Then you should report this as a bug.#012You 
can generate a local policy module to allow this access.#012Do#012allow 
this access for now by executing:#012# ausearch -c 'mycron' --raw | 
audit2allow -M my-mycron#012# semodule -X 300 -i my-mycron.pp#012
May 12 03:22:23 lx140e systemd[1]: 
dbus-:[e-mail]: Succeeded.
May 12 03:22:23 lx140e audit[1]: SERVICE_STOP pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='unit=dbus-:1.1-org.fedoraproject.Setroubleshootd@20 comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 12 03:22:23 lx140e systemd[1]: 
dbus-:[e-mail]: Consumed 3.306s 
CPU time.
May 12 03:22:25 lx140e systemd[1]: 
dbus-:[e-mail]: Succeeded.
May 12 03:22:25 lx140e audit[1]: SERVICE_STOP pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='unit=dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? 
terminal=? res=success'
May 12 03:22:25 lx140e systemd[1]: 
dbus-:[e-mail]: 
Consumed 5.271s CPU time.

# sealert -l 9fd5890f-400b-4ae0-8a98-43575ac4913a
Error
query_alerts error (1003): id (9fd5890f-400b-4ae0-8a98-43575ac4913a) not 
found