Re: permission problems with script run via crondargs -m

[Robert Moskowitz]

On 5/12/20 11:36 AM, Lukas Vrabec wrote:
> On 5/12/20 1:31 PM, Robert Moskowitz wrote:
> > 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
>
> Can you attach your "mycron" script? THere is some issue with SELinux
> domain transition.

Oh, and this script runs fine for root's crontab tasks.  It is failing 
on whatever kicks off logwatch.

permission problems with script run via crondargs -m

[Lukas Vrabec]

On 5/12/20 5:50 PM, Robert Moskowitz wrote:
> On 5/12/20 11:36 AM, Lukas Vrabec wrote:
> > On 5/12/20 1:31 PM, Robert Moskowitz wrote:
> > > 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
> >
> > Can you attach your "mycron" script? THere is some issue with SELinux
> > domain transition.
>
> Oh, and this script runs fine for root's crontab tasks.  It is failing
> on whatever kicks off logwatch.

Yes, that's the problem.

Can you please run:

# semanage fcontext -a -t sendmail_exec_t /usr/local/mycron
# restorecon -Rv /usr/local

and then reproduce it? This could help.

Thanks,
Lukas.
>

permission problems with script run via crondargs -m

[Robert Moskowitz]

On 5/12/20 12:13 PM, Lukas Vrabec wrote:
> On 5/12/20 5:50 PM, Robert Moskowitz wrote:
> > On 5/12/20 11:36 AM, Lukas Vrabec wrote:
> > > On 5/12/20 1:31 PM, Robert Moskowitz wrote:
> > > > 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
> > >
> > > Can you attach your "mycron" script? THere is some issue with SELinux
> > > domain transition.
> >
> > Oh, and this script runs fine for root's crontab tasks.  It is failing
> > on whatever kicks off logwatch.
>
> Yes, that's the problem.
>
> Can you please run:
>
> # semanage fcontext -a -t sendmail_exec_t /usr/local/mycron
> # restorecon -Rv /usr/local
>
> and then reproduce it? This could help.

restorecon -Rv /usr/local
Relabeled /usr/local/mycron from unconfined_u:object_r:usr_t:s0 to 
unconfined_u:object_r:sendmail_exec_t:s0

Interesting...

Now we will see what happens tonight.

permission problems with script run via crondargs -m

[Ed Greshko]

On 2020-05-13 00:51, Robert Moskowitz wrote:
> restorecon -Rv /usr/local
> Relabeled /usr/local/mycron from unconfined_u:object_r:usr_t:s0 to unconfined_u:object_r:sendmail_exec_t:s0
>
> Interesting...
>
> Now we will see what happens tonight.

You may want to consider trimming replies at some point so as not to have to overuse the the scroll
button?

permission problems with script run via crondargs -m

[Robert Moskowitz]

On 5/12/20 12:13 PM, Lukas Vrabec wrote:
> Oh, and this script runs fine for root's crontab tasks.  It is failing
> > on whatever kicks off logwatch.
>
> Yes, that's the problem.
>
> Can you please run:
>
> # semanage fcontext -a -t sendmail_exec_t /usr/local/mycron
> # restorecon -Rv /usr/local
>
> and then reproduce it? This could help.

It works now.  Thanks!

Of course I am changing my mycron script yet again!  I was shown how to 
use formail/procmail as a simple MDA.  Still need a script file, and 
probably still need all these selinux changes for it,

eventhough only procmail is touching /var/spool/mail/

permission problems with script run via crondargs -m

[Lukas Vrabec]

On 5/13/20 3:26 PM, Robert Moskowitz wrote:
> On 5/12/20 12:13 PM, Lukas Vrabec wrote:
> > Oh, and this script runs fine for root's crontab tasks.  It is failing
> > > on whatever kicks off logwatch.
> >
> > Yes, that's the problem.
> >
> > Can you please run:
> >
> > # semanage fcontext -a -t sendmail_exec_t /usr/local/mycron
> > # restorecon -Rv /usr/local
> >
> > and then reproduce it? This could help.
>
> It works now.  Thanks!

Great to hear that!
> Of course I am changing my mycron script yet again!  I was shown how to
> use formail/procmail as a simple MDA.  Still need a script file, and
> probably still need all these selinux changes for it,
>
> eventhough only procmail is touching /var/spool/mail/