linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* cifs.upcall broken with cifs-utils 6.13
@ 2021-04-20 16:05 Alexander Koch
  2021-04-20 16:41 ` Aurélien Aptel
  0 siblings, 1 reply; 5+ messages in thread
From: Alexander Koch @ 2021-04-20 16:05 UTC (permalink / raw)
  To: linux-cifs

The recent release of cifs-utils 6.13, more precisely e461afd8cf (which, 
to my understanding, is a fix for CVE-2021-20208) makes attempts of 
mounting CIFS shares with krb5 fail for me:

     cifs.upcall[78171]: switch_to_process_ns: setns() failed for cgroup
     cifs.upcall[78171]: unable to switch to process namespace: 
Operation not permitted


Can anyone tell me if this is a packaging/configuration issue (Arch in 
my case) or a bug?

Full mount log can be found in [1], along with a confirmation of the 
observed behaviour from another user.

Thanks!


Best regards,

Alex


[1] 
https://www.reddit.com/r/archlinux/comments/mukvv6/cifs_mount_broken_again_with_cifsutils6131/



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: cifs.upcall broken with cifs-utils 6.13
  2021-04-20 16:05 cifs.upcall broken with cifs-utils 6.13 Alexander Koch
@ 2021-04-20 16:41 ` Aurélien Aptel
  2021-04-20 17:02   ` Alexander Koch
  0 siblings, 1 reply; 5+ messages in thread
From: Aurélien Aptel @ 2021-04-20 16:41 UTC (permalink / raw)
  To: Alexander Koch, linux-cifs

Hi Alexander,

Alexander Koch <mail@alexanderkoch.net> writes:
> The recent release of cifs-utils 6.13, more precisely e461afd8cf (which, 
> to my understanding, is a fix for CVE-2021-20208) makes attempts of 
> mounting CIFS shares with krb5 fail for me:
>
> Can anyone tell me if this is a packaging/configuration issue (Arch in 
> my case) or a bug?

It's unfortunately a regression in the CVE fix. We are trying to come up
with a proper fix.

In the meantime, as a workaround:

* you can build cifs-utils --with-libcap=yes (libcap instead of libcapng). This will skip
  capability dropping in cifs.upcall.c.
* Alternatively you can comment out the call to trim_capabilities() in
  cifs.upcall.c.

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: cifs.upcall broken with cifs-utils 6.13
  2021-04-20 16:41 ` Aurélien Aptel
@ 2021-04-20 17:02   ` Alexander Koch
  2021-08-06  7:09     ` Alexander Koch
  0 siblings, 1 reply; 5+ messages in thread
From: Alexander Koch @ 2021-04-20 17:02 UTC (permalink / raw)
  To: Aurélien Aptel; +Cc: linux-cifs

Hi Aurélien,

>> The recent release of cifs-utils 6.13, more precisely e461afd8cf 
>> (which,
>> to my understanding, is a fix for CVE-2021-20208) makes attempts of
>> mounting CIFS shares with krb5 fail for me:
>> 
>> Can anyone tell me if this is a packaging/configuration issue (Arch in
>> my case) or a bug?
> 
> It's unfortunately a regression in the CVE fix. We are trying to come 
> up
> with a proper fix.
> 
> In the meantime, as a workaround:
> 
> * you can build cifs-utils --with-libcap=yes (libcap instead of
> libcapng). This will skip
>   capability dropping in cifs.upcall.c.
> * Alternatively you can comment out the call to trim_capabilities() in
>   cifs.upcall.c.

Thanks a million for the clarification. For me, downgrading the package 
to
6.12 works as an intermediate solution.

I'll open a task on the Arch bugtracker and let the package maintainer
decide what to do with the package until a proper fix is done.


Cheers,

Alex

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: cifs.upcall broken with cifs-utils 6.13
  2021-04-20 17:02   ` Alexander Koch
@ 2021-08-06  7:09     ` Alexander Koch
  2021-08-06  9:02       ` Pavel Shilovsky
  0 siblings, 1 reply; 5+ messages in thread
From: Alexander Koch @ 2021-08-06  7:09 UTC (permalink / raw)
  To: Aurélien Aptel; +Cc: linux-cifs

Hi Aurélien,

>> It's unfortunately a regression in the CVE fix. We are trying to come 
>> up
>> with a proper fix.

Any news about the proper fix for this regression?

I've seen there is no new release but maybe the is a patch that I could
propose for the maintainer of the 'cifs-utils' package in Arch in order 
to
work around this issue.

As of right now, the only working option is to keep the package 
downgraded
to 6.12.


Best regards,

Alex

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: cifs.upcall broken with cifs-utils 6.13
  2021-08-06  7:09     ` Alexander Koch
@ 2021-08-06  9:02       ` Pavel Shilovsky
  0 siblings, 0 replies; 5+ messages in thread
From: Pavel Shilovsky @ 2021-08-06  9:02 UTC (permalink / raw)
  To: Alexander Koch; +Cc: linux-cifs, Aurélien Aptel

пт, 6 авг. 2021 г. в 01:04, Alexander Koch <mail@alexanderkoch.net>:
>
> Hi Aurélien,
>
> >> It's unfortunately a regression in the CVE fix. We are trying to come
> >> up
> >> with a proper fix.
>
> Any news about the proper fix for this regression?
>
> I've seen there is no new release but maybe the is a patch that I could
> propose for the maintainer of the 'cifs-utils' package in Arch in order
> to
> work around this issue.
>
> As of right now, the only working option is to keep the package
> downgraded
> to 6.12.
>

Hi Alexander,

There is a patch that fixes the problem that will be included into the
next release:

https://github.com/piastry/cifs-utils/commit/7f9711dd902a239c499682015d708f73ec884af2

--
Best regards,
Pavel Shilovsky

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-08-06  9:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-20 16:05 cifs.upcall broken with cifs-utils 6.13 Alexander Koch
2021-04-20 16:41 ` Aurélien Aptel
2021-04-20 17:02   ` Alexander Koch
2021-08-06  7:09     ` Alexander Koch
2021-08-06  9:02       ` Pavel Shilovsky

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).