Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: "Björn JACKE" <bjacke@SerNet.DE>
To: Steve French <smfrench@gmail.com>
Cc: samba@lists.samba.org, linux-cifs@vger.kernel.org
Subject: Re: [Samba] samba-ad linux clients random access denied to network share
Date: Fri, 8 Apr 2022 11:09:02 +0200	[thread overview]
Message-ID: <20220408090902.GA1328207@sernet.de> (raw)
In-Reply-To: <CAH2r5mv9uS3=YJsRB=GPAebTSY+-oZ3nQQuNs5gAxknmMM-UVQ@mail.gmail.com>

Hello Steve and other cifs developers,

On 2022-04-07 at 16:25 -0500 Steve French via samba sent off:
> If you have particular hot bugs for cifs.ko that you need fixed - please
> let me know.

back in 2020 we've added the cifs mailing list as qa contact in bugzilla, so
that bugzilla bugs get more visible to the developers.

At the same point I also went through all the open bug reports of cifs vfs,
which had partly been very old. I also closed a bunch of them as they had been
fixed a while after they were reported there - but not because they were
reported in bugzilla obviously. I was hoping to improve that situation with bug
reports getting not enough attention my adding the cifs mailinglist as qa
contact, this was my motivation.

Just pointing out those bugs that I myself reported in bugzilla.samba.org in
2020, all stayed uncommented till today; except for the "better error message"
bug all of them are important for enterprise customers, this is also where they
popped up:

14398  	cifs vfs should pause if krb5 ticket is not valid 
14440   creator owner (S-1-3-0) ACE not honored 
14506   cifs mount with missing krb5 key should give better error message 
14507   cifs ACL exec permission granted where it should be denied 

And last but not least a big topic:

14499   expose NT ACLs via system.nfs4_acl EA 

This idea popped up in the discussion of the 2020 SambaXP discussion after your
talk. Having a standardized permission management tool like the nfs4-acl-tools
is really something that is important.

Also the fact that Linux still has no standardized ACL implementation (NFS4 ACL
are the only standardized ones) in the kernel is preventing many enterprise
customers to use Linux on client machines. Without that, permission management
is such a pain that they usually give up any client installation efforts sooner
or later.  I think the cifs vfs developers would have the power to convince the
responsible kernel developers to add this to the kernel.

I can say from my experience at various customer sites very clearly that cifs
vfs will *not* be accepted widely in the enterprise world, without generic NFS4
ACLs implemented in the kernel alongside.


> SMB3.1.1 is simpler in some ways than NFS (no SunRPC to deal with) and
> should be easier to fix bugs in many cases.

maybe it is simpler, but for the above mentioned reasons, SMB on the Linux
client side is no option for most enterprise environments. They prefer NFS and
I understand why. I really wish this would change, this is why I write these
lines so bluntly.

Björn
-- 
SerNet GmbH - Bahnhofsallee 1b - 37081 Göttingen
phone: +495513700000  mailto:contact@sernet.com
AG Göttingen: HR-B 2816 - https://www.sernet.com
Manag. Directors Johannes Loxen and Reinhild Jung
data privacy policy https://www.sernet.de/privacy

Samba eXPerience 2022 - online edition!
from May 31st to June 2nd, 2022 at Zoom
sponsored by Google, Microsoft & SerNet
more information at https://sambaXP.org

      parent reply	other threads:[~2022-04-08  9:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220406231135.024f1ea5@jeeg20151223.verlata.it>
     [not found] ` <48371ac062c13d0acb1ac4266e46ac65a49af023.camel@samba.org>
2022-04-07 11:51   ` [Samba] samba-ad linux clients random access denied to network share Björn JACKE
     [not found]     ` <CAH2r5mv9uS3=YJsRB=GPAebTSY+-oZ3nQQuNs5gAxknmMM-UVQ@mail.gmail.com>
2022-04-08  9:09       ` Björn JACKE [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220408090902.GA1328207@sernet.de \
    --to=bjacke@sernet.de \
    --cc=linux-cifs@vger.kernel.org \
    --cc=samba@lists.samba.org \
    --cc=smfrench@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox