linux-kernel - Re: [RFC PATCH 0/3] Rename "cifs" module to "smbfs"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220803144519.rn6ybbroedgmuaie@cyberdelia>
Date:   Wed, 3 Aug 2022 11:45:19 -0300
From:   Enzo Matsumiya <ematsumiya@...e.de>
To:     Jeff Layton <jlayton@...nel.org>
Cc:     linux-cifs@...r.kernel.org, smfrench@...il.com, pc@....nz,
        ronniesahlberg@...il.com, nspmangalore@...il.com,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        tom@...pey.com, samba-technical@...ts.samba.org,
        pshilovsky@...ba.org
Subject: Re: [RFC PATCH 0/3] Rename "cifs" module to "smbfs"

On 08/02, Jeff Layton wrote:
>If the concern is "branding" then I don't see how this really helps.
>Very few users interact with the kernel modules directly.
>
>FWIW, I just called "modprobe smb3" on my workstation and got this:
>
>[ 1223.581583] Key type cifs.spnego registered
>[ 1223.582523] Key type cifs.idmap registered
>[ 1230.411422] Key type cifs.idmap unregistered
>[ 1230.412542] Key type cifs.spnego unregistered
>
>Are you going to rename the keyrings too? That will have implications
>for userland helper programs like cifs.upcall. There's also
>/proc/fs/cifs/*.
>
>These are a "stable interfaces" that you can't just rename at will. If
>you want to change these interfaces then you need to do a formal
>deprecation announcement, and probably a period with /proc/fs/smbfs and
>/proc/fs/cifs coexisting.
>
>There are also a ton of printk's and such that have "CIFS" in them that
>will need to be changed.
>
>These costs do not seem worth the perceived benefit to me. You could
>probably hide a lot of what users see by just renaming (or symlinking)
>mount.cifs to mount.smb3.
>
>I think if you guys are serious about this, you should probably start
>somewhere else besides renaming the directory and module. This is going
>to impact developers (and people who make their living doing backports)
>far more than it will users.

I was thinking about the possible issues of a rename, and my
perspective/assessment of the impact is this:

For devs:
- from running userspace/upcall tools with "cifs" name for a while until
   everything eventually catches up
- not much else, really (enlighten me here please)

For backporters/distros:
- this might *look* like an issue first, because of the name conflicts it
   would arise when backporting fixes to older kernels, but these are
   _just_ a rename, without any functional changes whatsoever. It could
   be backported just fine as well, and customers/end users would still
   see no difference in behaviour

For customers/end users:
- at first, there should be no impact. "cifs" and "smb3" modules aliases
   are kept (and will be for a long while) and nothing else changes
   (procfs entry, idmap/spnego upcalls, mount.cifs, etc stays the same)

A note on backports: I myself (and Paulo) do the backports for our SLE
products, sometimes down to SLE11-SP4 (based on kernel 3.0) and I
could not see what other issues could appear given if we backport this
rename to released products.

Of course, I don't know every process for every distro vendors, so if
someone could provide feedback on this, I'd appreciate.

@Paulo I'd like to hear your opinion on possible issues of future backports,
if we backported this rename patch to SLES.


Cheers,

Enzo