Bug 1158910 (CVE-2020-8017)

I have here a problem as group mktex is not allowed to do the job

 su -g mktex - nobody
 nobody@noether:~> id
 uid=65534(nobody) gid=487(mktex) groups=487(mktex)
 nobody@noether:~> ll /var/cache/texmf/fonts/tfm/
 total 0
 -rw-rw-r-- 1 root mktex 0 Dec 11 13:05 xyz
 nobody@noether:~> rm /var/cache/texmf/fonts/tfm/xyz
 rm: cannot remove '/var/cache/texmf/fonts/tfm/xyz': Operation not permitted
 nobody@noether:~> ll /var/cache/texmf/fonts/tfm/ -d
 drwxrwxr-t 2 root mktex 17 Dec 11 13:05 /var/cache/texmf/fonts/tfm/

...the sticky bit breaks this!

(In reply to Dr. Werner Fink from comment #1)
> I have here a problem as group mktex is not allowed to do the job
> [...]
> ...the sticky bit breaks this!

I see. That is unfortunate and complicates things. Which component is creating these files in the first place?

I see only two approaches left:

1) try to change the creation of these files in a way that they're also owned by 'mktex', then fix the ownership once during package update (which again is a security sensitive operation)
2) try the systemd-tmpfiles route, I think it operates as root but uses a safe file access algorithm to delete files owned by unprivileged users.

As normal user creates their file below ~/.config/texmf/ there is no need to run any suid program, I simply use rm(1) now for the files root write and creates.
And only user root switch over to user nobody and group mktex

This is an autogenerated message for OBS integration:
This bug (1158910) was mentioned in
https://build.opensuse.org/request/show/756829 Factory / texlive-filesystem

(In reply to werner@suse.com from comment #3)
> As normal user creates their file below ~/.config/texmf/ there is no need to
> run any suid program, I simply use rm(1) now for the files root write and
> creates.

Thank you for working on this!

> And only user root switch over to user nobody and group mktex

This part still seems to be missing. suse-texlive now uses rm instead of
safe-rm, but still operates as root on /var/cache/texmf/fonts. Are you still
working on this?

(In reply to Matthias Gerstner from comment #5)
> (In reply to werner@suse.com from comment #3)
> > As normal user creates their file below ~/.config/texmf/ there is no need to
> > run any suid program, I simply use rm(1) now for the files root write and
> > creates.
> 
> Thank you for working on this!
> 
> > And only user root switch over to user nobody and group mktex
> 
> This part still seems to be missing. suse-texlive now uses rm instead of
> safe-rm, but still operates as root on /var/cache/texmf/fonts. Are you still
> working on this?

Only root uses /var/cache/texmf/fonts and for this root switch to nobody:mktex, all other users do use their ~/.cache/texmf/fonts/ ... this is the default configuration.

To see this run

  mktexpk cmr8

as user and as root, then do

  find /var/cache/texmf/fonts -ls

as well as user

  find ~/.cache/texmf/fonts -ls

(In reply to werner@suse.com from comment #7)
> To see this run
> 
>   mktexpk cmr8
> 
> as user and as root, then do
> 
>   find /var/cache/texmf/fonts -ls
> 
> as well as user
> 
>   find ~/.cache/texmf/fonts -ls

Ah you mean the files are only *created* by nobody:mktex. But they're still
deleted by root.

This still leaves open a privilege escalation. If the mktex group is
compromised then arbitrary files can be deleted when the cron job is executed.

Can you please also do the deletion as nobody:mktex?

(In reply to Matthias Gerstner from comment #8)
> (In reply to werner@suse.com from comment #7)
> > To see this run
> > 
> >   mktexpk cmr8
> > 
> > as user and as root, then do
> > 
> >   find /var/cache/texmf/fonts -ls
> > 
> > as well as user
> > 
> >   find ~/.cache/texmf/fonts -ls
> 
> Ah you mean the files are only *created* by nobody:mktex. But they're still
> deleted by root.
> 
> This still leaves open a privilege escalation. If the mktex group is
> compromised then arbitrary files can be deleted when the cron job is
> executed.
> 
> Can you please also do the deletion as nobody:mktex?

You have to nobody or root, as all directories are sticky by default. The group mktex is simply not enough ... run the commands I've shown and see

(In reply to werner@suse.com from comment #9)
> You have to nobody or root, as all directories are sticky by default. The
> group mktex is simply not enough ... run the commands I've shown and see

Ah right the thing with the sticky bit. Anyways there remains a symlink attack
vector the way this is currently done. If you really need to have root
permissions to remove files in there then you need to use a program that is
prepared to handle such that, like `tmpwatch` or `systemd-tmpfiles`.

Why are there files owned by root beneath /var/cache/texmf/fonts in the first
place? It seems something is off there, too. It's not symmetric. Whatever
user:group combination is creating these files should also delete them. Then
there's no trouble with sticky bits and no trouble with security.

Looking more closely at texlive-filesystem the following additional problems
appear:

a) when freshly installed /var/cache/texmf/fonts/ls-R (and others) are owned by
  root:mktex. The source of this is in the spec file:

>  %post
>  %fillup_only -n texlive
>  # the ls-R file (empty at package time)
>  for dir in	%{_texmfconfdir}	\
>  		%{_fontcache}		\
>  		%{_texmfvardir}		\
>  		%{_texmfvardir}/dist	\
>  		%{_texmfvardir}/main
>  do
>      test ! -e ${dir}/ls-R || continue
>      echo '%% ls-R -- filename database for kpathsea; do not change this line.' > \
>      ${dir}/ls-R
>      chown root:%{texgrp} ${dir}/ls-R || :
>      chmod 0664 ${dir}/ls-R || :
>  done

  This echo line opens up a symlink attack. If for example you try the
  following:

>  root# rm /var/cache/texmf/fonts/ls-R
>  nobody# ln -s /var/cache/texmf/fonts/ls-R
>  root# zypper in -f texlive-filesystem
>  [...]
>  root# ls -lh /root/ls-R
>  -rw-rw-r-- 1 root mktex 67 18. Dez 15:17 /root/ls-R

b) When newly creating ls-R files then they're not owned by root:mktex but by
   nobody:mktex:

>  root# rm /var/cache/texmf/fonts/ls-R
>  root# mktexlsr
>  root# ls -lh /var/cache/texmf/fonts/ls-R
>  -rw-rw-r-- 1 nobody mktex 217 18. Dez 15:19 /var/cache/texmf/fonts/ls-R

   So there is some disagreement between what the packaging does (spec file)
   and what mktexlsr does when the files aren't existing yet.

   If the files would be owned by nobody:mktex in the first place then there
   would be no trouble deleting them safely.

c) This generally raises the question why those directories have a sticky
   directory in the first place. They're not writable by other, so it's not
   actually public directories. Maybe they should not a sticky bit at all and
   be owned by nobody:mktex?

(In reply to Matthias Gerstner from comment #10)

Deja vu, every few years the same discussion with security ;}

> 
> a) when freshly installed /var/cache/texmf/fonts/ls-R (and others) are owned
> by
>   root:mktex. The source of this is in the spec file:
> 
> >  %post
> >  %fillup_only -n texlive
> >  # the ls-R file (empty at package time)
> >  for dir in	%{_texmfconfdir}	\
> >  		%{_fontcache}		\
> >  		%{_texmfvardir}		\
> >  		%{_texmfvardir}/dist	\
> >  		%{_texmfvardir}/main
> >  do
> >      test ! -e ${dir}/ls-R || continue
> >      echo '%% ls-R -- filename database for kpathsea; do not change this line.' > \
> >      ${dir}/ls-R
> >      chown root:%{texgrp} ${dir}/ls-R || :
> >      chmod 0664 ${dir}/ls-R || :
> >  done

On a fresh installation there is normally no /var/cache/texmf/fonts/
on update there is always a /var/cache/texmf/fonts/ls-R which will be
always overwritten by mktexlsr

>   This echo line opens up a symlink attack. If for example you try the
>   following:
> 
> >  root# rm /var/cache/texmf/fonts/ls-R

Root can do anything right, but normally mktexlsr is used
and this overwrites  *always* the already *existing* file

> >  nobody# ln -s /var/cache/texmf/fonts/ls-R

And how have you become nobody ... only root can do, right?
If you are root you can do anything.

> >  root# zypper in -f texlive-filesystem
> >  [...]
> >  root# ls -lh /root/ls-R
> >  -rw-rw-r-- 1 root mktex 67 18. Dez 15:17 /root/ls-R
> 
> b) When newly creating ls-R files then they're not owned by root:mktex but by
>    nobody:mktex:

Yes, as said ls-R will never removed, but only overwritten. the ownership
is for the fonts only.

> >  root# rm /var/cache/texmf/fonts/ls-R
> >  root# mktexlsr
> >  root# ls -lh /var/cache/texmf/fonts/ls-R
> >  -rw-rw-r-- 1 nobody mktex 217 18. Dez 15:19 /var/cache/texmf/fonts/ls-R
> 
>    So there is some disagreement between what the packaging does (spec file)
>    and what mktexlsr does when the files aren't existing yet.
> 
>    If the files would be owned by nobody:mktex in the first place then there
>    would be no trouble deleting them safely.
> 
> c) This generally raises the question why those directories have a sticky
>    directory in the first place. They're not writable by other, so it's not
>    actually public directories. Maybe they should not a sticky bit at all and
>    be owned by nobody:mktex?

In the current configuration it is NOT public, but you could it configure as
public, yes. For this /etc/texmf/web2c/mktex.cnf is used together with
/usr/share/texmf/web2c/mktex.opt to do the various jobs for root and all
other users.  To allow all users you could indead make /var/cache/texmf/fonts/
writable for every user by runnging

  chmod a+w /var/cache/texmf/fonts/

hence there exists a predefined sticky bit to hold the now tmeporary directory
secure.  And as ls-R is owned by root(:mktex) only root can overwrite this
file (with mktexlsr!)  but indeed root should never rmeove it.

Forgotten one other methode ... add TeX users to the group mktex, then also the varfonts option will allow those users to write below /var/cache/texmf/fonts/.

The reason for a) all user method and b) group mktex method allows to reduce the required amount of disk space at font generation. Otherwise all fonts will generated below the personal ~/.cache/texm/fonts/ directory for every user them self.

Using mktemp might avoid symlink attacks from root to root

@@ -42,6 +42,8 @@
 Requires(pre):  /usr/sbin/groupadd
 Requires(post): %fillup_prereq
 Requires(post): permissions
+Requires(post): /usr/bin/mktemp
+Requires(post): /usr/bin/mv
 Requires(pre):  /usr/bin/perl
 Requires(pre):  /usr/bin/clear
 Requires(pre):  /usr/bin/dialog
@@ -351,6 +353,7 @@
 %post
 %fillup_only -n texlive
 # the ls-R file (empty at package time)
+error=0
 for dir in     %{_texmfconfdir}        \
                %{_fontcache}           \
                %{_texmfvardir}         \
@@ -358,10 +361,16 @@
                %{_texmfvardir}/main
 do
     test ! -e ${dir}/ls-R || continue
+    tmp=$(mktemp ${dir}/ls-R.XXXXXX) || error=1
+    test $error = 0 || continue
+    mv ${tmp} ${dir}/ls-R || error=1
+    test $error = 0 || continue
+    chown root:%{texgrp} ${dir}/ls-R || error=1
+    test $error = 0 || continue
+    chmod 0664 ${dir}/ls-R || error=1
+    test $error = 0 || continue
     echo '%% ls-R -- filename database for kpathsea; do not change this line.' > \
     ${dir}/ls-R
-    chown root:%{texgrp} ${dir}/ls-R || :
-    chmod 0664 ${dir}/ls-R || :
 done
 %if %{defined set_permissions}
 %set_permissions %{_texmfconfdir}/ls-R
@@ -386,6 +395,7 @@
 mkdir -p /var/run/texlive
 > /var/run/texlive/run-mktexlsr
 > /var/run/texlive/run-update
+test $error = 0 || exit 1

This is an autogenerated message for OBS integration:
This bug (1158910) was mentioned in
https://build.opensuse.org/request/show/758097 Factory / texlive-filesystem

(In reply to Dr. Werner Fink from comment #11)

> Deja vu, every few years the same discussion with security ;}

Well maybe the discussion was never quite finished, hence we still have the same problems ;)
 
> On a fresh installation there is normally no /var/cache/texmf/fonts/
> on update there is always a /var/cache/texmf/fonts/ls-R which will be
> always overwritten by mktexlsr
> 
> >   This echo line opens up a symlink attack. If for example you try the
> >   following:
> > 
> > >  root# rm /var/cache/texmf/fonts/ls-R
> 
> Root can do anything right, but normally mktexlsr is used
> and this overwrites  *always* the already *existing* file

This is just a simulation, an attacker can use the race condition, because firs the fonts directory is created with the sticky bit and only afterwards the ls-R file is created (on a fresh installation).
 
> > >  nobody# ln -s /var/cache/texmf/fonts/ls-R
> 
> And how have you become nobody ... only root can do, right?
> If you are root you can do anything.

This is just another simulation of a compromised nobody account.
 
> > b) When newly creating ls-R files then they're not owned by root:mktex but by
> >    nobody:mktex:
> 
> Yes, as said ls-R will never removed, but only overwritten. the ownership
> is for the fonts only.

But why then this change in behaviour between newly created files (even if they're never supposed to be newly created this way) and overwritten files? Why not have this file owned by nobody:mktex in the first place?
 
> In the current configuration it is NOT public, but you could it configure as
> public, yes.

So the sticky bit is a preparation in case an Admin wants to make it public. Understood.

>      test ! -e ${dir}/ls-R || continue
> +    tmp=$(mktemp ${dir}/ls-R.XXXXXX) || error=1
> +    test $error = 0 || continue
> +    mv ${tmp} ${dir}/ls-R || error=1
> +    test $error = 0 || continue
> +    chown root:%{texgrp} ${dir}/ls-R || error=1
> +    test $error = 0 || continue
> +    chmod 0664 ${dir}/ls-R || error=1
> +    test $error = 0 || continue
>      echo '%% ls-R -- filename database for kpathsea; do not change this line.' > \
>      ${dir}/ls-R
> -    chown root:%{texgrp} ${dir}/ls-R || :
> -    chmod 0664 ${dir}/ls-R || :

I'm not sure this will actually fix the attack surface. I'll leave this to
jsegitz who has just recently been hunting down such attacks in %pre/%post
sections, but he didn't catch this particular one.

We'll actually need a separate bug for this spec file part. That was just a
by-catch. In this bug here may main concern is still the cron job recursively
deleting outdated files in /var/cache/texmf with race conditions involved.

> 
> This is just a simulation, an attacker can use the race condition, because
> firs the fonts directory is created with the sticky bit and only afterwards
> the ls-R file is created (on a fresh installation).
>  
> > > >  nobody# ln -s /var/cache/texmf/fonts/ls-R
> > 
> > And how have you become nobody ... only root can do, right?
> > If you are root you can do anything.
> 
> This is just another simulation of a compromised nobody account.

Fact is that tools like mktexlsr do always overwrite existing ls-R
files.  And yes one of them is a symlink from below /usr/share/texmf/
while possible be mounted r/o whereas the targets of this link is
located at /var/lib/texmf/main/ls-R.
  
> > > b) When newly creating ls-R files then they're not owned by root:mktex but by
> > >    nobody:mktex:
> > 
> > Yes, as said ls-R will never removed, but only overwritten. the ownership
> > is for the fonts only.
> 
> But why then this change in behaviour between newly created files (even if
> they're never supposed to be newly created this way) and overwritten files?
> Why not have this file owned by nobody:mktex in the first place?

As only members of the group mktex or root its self can overwrite the ls-R
database file, e.g. on creation of new font files an updateing the ls-R
file afterwards.

>  
> > In the current configuration it is NOT public, but you could it configure as
> > public, yes.
> 
> So the sticky bit is a preparation in case an Admin wants to make it public.
> Understood.

Exactly, suppose that there are members of the mktex group which are working
on a larger TeX projects like books with a third party fonts.  Clearly those
members have to be reliable workers. The advantage is, that the different
resolutions of the fonts are not located in on several personal chach fonts
but only once below /var/cache/texmf/fonts/

And if the admin trust *all* members of a institution/department then he/she
can do the chmod a+w on /var/cache/texmf/fonts/

> 
> >      test ! -e ${dir}/ls-R || continue
> > +    tmp=$(mktemp ${dir}/ls-R.XXXXXX) || error=1
> > +    test $error = 0 || continue
> > +    mv ${tmp} ${dir}/ls-R || error=1
> > +    test $error = 0 || continue
> > +    chown root:%{texgrp} ${dir}/ls-R || error=1
> > +    test $error = 0 || continue
> > +    chmod 0664 ${dir}/ls-R || error=1
> > +    test $error = 0 || continue
> >      echo '%% ls-R -- filename database for kpathsea; do not change this line.' > \
> >      ${dir}/ls-R
> > -    chown root:%{texgrp} ${dir}/ls-R || :
> > -    chmod 0664 ${dir}/ls-R || :
> 
> I'm not sure this will actually fix the attack surface. I'll leave this to
> jsegitz who has just recently been hunting down such attacks in %pre/%post
> sections, but he didn't catch this particular one.
> 
> We'll actually need a separate bug for this spec file part. That was just a
> by-catch. In this bug here may main concern is still the cron job recursively
> deleting outdated files in /var/cache/texmf with race conditions involved.

For cases where ls-R got delete and was recreated with nobody:mktex there's a race window if an attacker (nobody and group mktex) can get in between the stat and the mv. It's really hard to win though

But I'm wondering as Matthias if it's not easier to just have all these files and directories owned by nobody from the beginning and then operate with these privileges there. You basically do that with your public binary and the asymmetry between the packaged files and possible configurations after administrative changes makes this more complex.

So I've split-off bug 1159740 for separate discussion of the spec file race
condition, dirs with sticky bits and inconsistent ls-R ownership.

Coming back to the original cron job race condition. The exploit in attachment
826677 [details] demonstrates how a compromised member of the mktex group can cause
arbitrary files to be deleted. It can be used like this:

```
root# zypper in texlive-filesystem
root# zypper in --no-recommends texlive-kpathsea-bin

root# # this will attempt to get /etc/raw deleted
root# su -g mktex nobody /path/to/texlive_cron_race.sh

root# # in a second terminal simply repeatedly run the cron job until the
root# # exploit succeeds.
root# /etc/cron.d/suse-texlive
```

The race condition can be won every two to three times on my test system. This
is the attack vector that needs to be fixed in this bug.

This is an autogenerated message for OBS integration:
This bug (1158910) was mentioned in
https://build.opensuse.org/request/show/762831 Factory / texlive-filesystem

Please test if SR#762831 and SR#763971 do fix this bug

Ping! Any news on my question?

Sorry for the late reply, I was loaded with other topics recently.

The changes in SR#762831 look promising. Directories are now owned by nobody:mktex, the deletion logic runs using setpriv under nobody:mktex. safe-rm and safe-rmdir is no longer used. I think this adresses this bug here. Thank you!

Not sure about SR#763971 which got superseded a couple of times and doesn't seem to contain anything related to this bug.

Can you backport the changes to SLE-12 and SLE-15?

Thank you for working on the safe-rm* removal. From my point of view this bug is finished. I'm reassigning to security-team since they are tracking this finding on the reactive security side, so it's left for them to close the bug.

I'm decoupling this bug from the cron-job audit, it's no longer a blocker there.

Back to me as not fixed ... the owner ship has to be root:mktex for /var/cache/texmf/fonts/ font cache tree ... compare with boo#1159740

Changes affecting this bug have been commented on in bug 1159740. The current
changes are still not fixing the problem at hand.

In accordance with out new security policy [1], I'm setting a latest
publication date for this issue - fixed or not - based on the creation date of
this bug:

Internal CRD: 2020-03-09 or earlier

[1]: https://en.opensuse.org/openSUSE:Security_disclosure_policy

The issue in the cron job is tracked as CVE-2020-8017

(In reply to  werner@suse.com from bug 1159740 comment 37)
> See latest submit requests for texlive and texlive-filesystem

So there you changed things in the spec file, but not the cron job?

The cron job as quoted in bug 1159740 comment 33 is at the root of the problem
here, because it still uses dynamics that allows the mktex user to trick root
into deleting privileged files.

The `setpriv --reuid $uid` needs to be changed to `setpriv --reuid mktex`, the
UID lookup logic be removed, the sticky bit directories again be owned by
the unprivileged user.

I've lost track of your many submissions but you had this basically in IBS
sr#209865, only using the nobody user.

(In reply to Matthias Gerstner from comment #32)
> (In reply to  werner@suse.com from bug 1159740 comment 37)
> > See latest submit requests for texlive and texlive-filesystem
> 
> So there you changed things in the spec file, but not the cron job?
> 
> The cron job as quoted in bug 1159740 comment 33 is at the root of the
> problem
> here, because it still uses dynamics that allows the mktex user to trick root
> into deleting privileged files.
> 
> The `setpriv --reuid $uid` needs to be changed to `setpriv --reuid mktex`,
> the
> UID lookup logic be removed, the sticky bit directories again be owned by
> the unprivileged user.
> 
> I've lost track of your many submissions but you had this basically in IBS
> sr#209865, only using the nobody user.

See attachment #831040 [details] for spec file .... btw. it is regardless if ls-R belongs to user root or user mktex.    The mktex utilities like mktexlsr do not and never had executed as user root but as user mktex (former user nobody) within group mktex due to the utility /usr/lib/mktex/public (for source see attachment #831047 [details]) since 2010 ... and before 2010 there was a patch for mktexlsr to use su to switch to user nobody before doing the final ``ls -R`` command

```
 id uid=0(root) gid=0(root) groups=0(root)
 ll /var/cache/texmf/fonts/ls-R
 lrwxrwxrwx 1 mktex mktex 15 Feb 25 12:58 /var/cache/texmf/fonts/ls-R -> /etc/hosts.test
  mktexlsr 
 warning: kpathsea: /var/cache/texmf/fonts/ls-R: No usable entries in ls-R.
 warning: kpathsea: See the manual for how to generate ls-R. 
 warning: kpathsea: /var/cache/texmf/fonts/ls-R: No usable entries in ls-R.
 warning: kpathsea: See the manual for how to generate ls-R.
 mktexlsr: Updating /etc/texmf/ls-R... 
 mktexlsr: Updating /var/lib/texmf/main/ls-R... 
 mktexlsr: /etc/hosts.test: no write permission, skipping...
 mktexlsr: Updating /var/lib/texmf/ls-R... 
 mktexlsr: Done.
```

(In reply to Dr. Werner Fink from comment #33)
> The mktex utilities like mktexlsr do not and never had executed as user root but as user mktex

The issue isn't mktexlsr. %post and %pre run as root. Anything you do there without special precautions like setpriv will run as root and can be problematic if it operates on assumptions that can be broken by unprivileged users (e.g. chown'ing a file that might not be what you think it is).

I prepared a safe version in 
home:jsegitz:branches:Publishing:TeXLive/texlive-filesystem
Basically it just separates the creation of the ls-R file in /var/cache/texmf/fonts/ and keeps the remaining logic.

With the correct entries in the permission.d entries that reflect the ownership of /var/cache/texmf/fonts/ls-R it also removes the warnings you saw

(In reply to Johannes Segitz from comment #34)

> I prepared a safe version in 
> home:jsegitz:branches:Publishing:TeXLive/texlive-filesystem
> Basically it just separates the creation of the ls-R file in
> /var/cache/texmf/fonts/ and keeps the remaining logic.

OK ... with this I'd like to suggest something like the following

```
error=0
user=
for dir in      %{_texmfconfdir}        \
                %{_fontcache}           \
                %{_texmfvardir}         \
                %{_texmfvardir}/dist    \
                %{_texmfvardir}/main
do
    test "$dir" = %{_fontcache} && user=%{texusr} || user=root
    setpriv --reuid $user --regid mktex --init-groups /bin/sh -ec "     
        tmp=\$(mktemp ${dir}/ls-R.XXXXXX)
        chmod 0664 \${tmp}
        echo '%% ls-R -- filename database for kpathsea; do not change this line.' > \${tmp}
        mv \${tmp} ${dir}/ls-R" || error=1
done
```

Does the same job, only the setpriv is used for each ls-R once wit the help of a string command list for /bin/sh ... at least it does work here as the ``mv`` command will overwrite even symbolic links or simply fail if it can not do this.

(In reply to Dr. Werner Fink from comment #35)
yes, that is a secure solution and also more elegant since it avoids extracting the special case of %{_fontcache}.

SUSE-SU-2020:0520-1: An update that contains security fixes can now be installed.

Category: security (moderate)
Bug References: 1150556,1155381,1158910,1159740
CVE References: 
Sources used:
SUSE Linux Enterprise Software Development Kit 12-SP5 (src):    texlive-filesystem-2013.74-16.5.1
SUSE Linux Enterprise Software Development Kit 12-SP4 (src):    texlive-filesystem-2013.74-16.5.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2020:0519-1: An update that contains security fixes can now be installed.

Category: security (moderate)
Bug References: 1150556,1155381,1158910,1159740
CVE References: 
Sources used:
SUSE Linux Enterprise Module for Desktop Applications 15-SP1 (src):    texlive-filesystem-2017.135-9.5.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

When can I submit to Tumbleweed/Factory

(In reply to Dr. Werner Fink from comment #40)
The spec file can be submitted right away. I need to have another look at the cron job, I'll comment in bsc#1159740

(In reply to Johannes Segitz from comment #41)
sorry, I switched the bugs since we had the final discussion for the spec file here. So the spec file is fine and I'll comment here once I had a final look at the cron-job

I agree with the assessment of Matthias. Can you please go back to the logic submitted in sr#209865 and change setpriv to use mktex instaed of nobody? With that it would be fine to submit to Factory too.

Created attachment 832111 [details]
texlive.cron

(In reply to Johannes Segitz from comment #43)
> I agree with the assessment of Matthias. Can you please go back to the logic
> submitted in sr#209865 and change setpriv to use mktex instaed of nobody?
> With that it would be fine to submit to Factory too.

Ah?  I use mktex resp. the user how has created the files and this is what I've already committed

Yes, I've seen that, but you also have the logic that first looks for the uids used and then iterates over all of them, calling setpriv with reuid 0 at one point. 

I couldn't find a way to misuse that though in the current setup, although I would prefer a less complex solution. So from my POV we're done here, please submit to Factory. Matthias will ensure that the current cron job is whitelisted accordingly.

This is an autogenerated message for OBS integration:
This bug (1158910) was mentioned in
https://build.opensuse.org/request/show/787537 Factory / texlive-filesystem

openSUSE-SU-2020:0368-1: An update that contains security fixes can now be installed.

Category: security (moderate)
Bug References: 1150556,1155381,1158910,1159740
CVE References: 
Sources used:
openSUSE Leap 15.1 (src):    texlive-filesystem-2017.135-lp151.8.3.1

done

SUSE-SU-2020:1580-1: An update that fixes two vulnerabilities is now available.

Category: security (moderate)
Bug References: 1158910,1159740
CVE References: CVE-2020-8016,CVE-2020-8017
Sources used:
SUSE Linux Enterprise Module for Desktop Applications 15-SP1 (src):    texlive-2017.20170520-11.13.2, texlive-filesystem-2017.135-9.12.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2020:1581-1: An update that solves two vulnerabilities and has one errata is now available.

Category: security (moderate)
Bug References: 1138793,1158910,1159740
CVE References: CVE-2020-8016,CVE-2020-8017
Sources used:
SUSE Linux Enterprise Software Development Kit 12-SP5 (src):    texlive-2013.20130620-22.8.2, texlive-filesystem-2013.74-16.12.1
SUSE Linux Enterprise Software Development Kit 12-SP4 (src):    texlive-2013.20130620-22.8.2, texlive-filesystem-2013.74-16.12.1
SUSE Linux Enterprise Server 12-SP5 (src):    texlive-2013.20130620-22.8.2
SUSE Linux Enterprise Server 12-SP4 (src):    texlive-2013.20130620-22.8.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

openSUSE-SU-2020:0804-1: An update that fixes two vulnerabilities is now available.

Category: security (moderate)
Bug References: 1158910,1159740
CVE References: CVE-2020-8016,CVE-2020-8017
Sources used:
openSUSE Leap 15.1 (src):    texlive-2017.20170520-lp151.12.3.1, texlive-filesystem-2017.135-lp151.8.6.1

SUSE-SU-2020:1580-2: An update that fixes two vulnerabilities is now available.

Category: security (moderate)
Bug References: 1158910,1159740
CVE References: CVE-2020-8016,CVE-2020-8017
Sources used:
SUSE Linux Enterprise Module for Desktop Applications 15-SP2 (src):    texlive-filesystem-2017.135-9.12.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

Done