Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #74363 > unrolled thread

Bug#1005236: nfs-kernel-server 1.3.4 does not support security_label option for SELinux over NFS 4.2

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1005236: nfs-kernel-server 1.3.4 does not support security_label option for SELinux over NFS 4.2 Tongliang Liao <xkszltl@gmail.com> - 2022-02-09 20:00 +0100
    Bug#1005236:  Andreas Hasenack <andreas@canonical.com> - 2022-02-10 14:10 +0100
    Bug#1005236: closing 1005236 Salvatore Bonaccorso <carnil@debian.org> - 2022-02-10 14:40 +0100
      Bug#1005236: closing 1005236 Tongliang Liao <xkszltl@gmail.com> - 2022-02-10 14:50 +0100

#74363 — Bug#1005236: nfs-kernel-server 1.3.4 does not support security_label option for SELinux over NFS 4.2

Package: nfs-kernel-server
Version: 1:1.3.4-6
Severity: important
X-Debbugs-Cc: xkszltl@gmail.com


This is was initially handled by RHEL:
- https://bugzilla.redhat.com/show_bug.cgi?id=1406885

To summarize:
- SELinux label can be forwarded to client in NFS 4.2
- Kernel enabled that behavior by default for a while, and then disabled it later on due to complaints.
- Now it requires option `security_label` in export list.
- Debian 11's stock NFS doesn't support this option (`exportfs: /etc/exports:2: unknown keyword "security_label"` from `systemctl start nfs-server`).
- Debian can handle NFS 4.2 well and see remote SELinux labels as client, but cannot export its own when using as server.

There's an fix in upstream, which is only in 1.3.5-rc6:
- https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=13e2f9577b88d44001b509e89122ad907805b250

Prefer to have it backported (only a few lines of diff) to a stable version.
RedHat has done that for 1.3.0.
Or alternatively ship the rc version if it's stable enough.


-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp  56383  mountd
    100005    1   tcp  39155  mountd
    100005    2   udp  44594  mountd
    100005    2   tcp  33081  mountd
    100005    3   udp  51860  mountd
    100005    3   tcp  52315  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049
    100003    3   udp   2049  nfs
    100227    3   udp   2049
    100021    1   udp  53134  nlockmgr
    100021    3   udp  53134  nlockmgr
    100021    4   udp  53134  nlockmgr
    100021    1   tcp  39965  nlockmgr
    100021    3   tcp  39965  nlockmgr
    100021    4   tcp  39965  nlockmgr
-- /etc/default/nfs-kernel-server --
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids"
NEED_SVCGSSD=""
RPCSVCGSSDOPTS=""
-- /etc/exports --
/Latte           10.0.0.0/8(rw,nohide,insecure,sync)
-- /proc/fs/nfs/exports --
# Version 1.1
# Path Client(Flags) # IPs
/Latte	10.0.0.0/8(rw,insecure,root_squash,sync,wdelay,nohide,no_subtree_check,uuid=f8703289:004ce25b:00000000:00000000,sec=1)

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-11-amd64 (SMP w/36 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages nfs-kernel-server depends on:
ii  keyutils      1.6.1-2
ii  libblkid1     2.36.1-8+deb11u1
ii  libc6         2.31-13+deb11u2
ii  libcap2       1:2.44-1
ii  libsqlite3-0  3.34.1-3
ii  libtirpc3     1.3.1-1
ii  libwrap0      7.6.q-31
ii  lsb-base      11.1.0
ii  netbase       6.3
ii  nfs-common    1:1.3.4-6
ii  ucf           3.0043

nfs-kernel-server recommends no packages.

nfs-kernel-server suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#74382 — Bug#1005236:

> I'm not familiar of changes in nfs-utils. Given the major version update and the
> fact that both Debian 11/Sid haven't included v2, I guess it's either not well-
> tested on Debian, or has breaking changes that most people don't want?

I've been looking at the exp package lately, since I'm trying to
update[1] the ubuntu nfs-utils package as well, which we neglected for
many releases.

There are upstream changes, and packaging changes, and a question on
how to handle upgrades.

src:libnfsidmap and src:libnfsidmap-regex were pulled[2][3] into
upstream's nfs-utils (in 2017 and 2020, respectively), which deprecate
those source packages in debian and ubuntu. libnfsidmap actually
forked, and got some new features like LDAP_tls_reqcert config
support[4] and SASL binds[5] in its new home in nfs-utils, for
example, besides plenty of fixes.

Upstream's most visible change is probably the configuration. Instead
of a complicated mechanism to source different configuration files
(/etc/sysconfig in RH, /etc/default/nfs-* in debian/ubuntu), and then
adjust command-line options to all the different daemons, upstream now
changed the daemons themselves to read a new /etc/nfs.conf ini-style
config file[6]. Fedora has a python conversion script[7] that they use
as a one-shot systemd service unit[8]. I played[9] with it a little
and we can easily make it work with debian/ubuntu, and that opens up
some paths for us to handle the migration.

Maybe the only reason to keep the /etc/default/nfs-* files is for sysv
initscripts, to be able to run or not a particular service
(NEED_<foo>=yes|no), if that's still an objective. For systemd, it
will be the usual systemctl enable/disable/mark/unmask.

The old nfs-config.service unit is gone, since there is no need to
generate an aggregated config file for the different systemd units to
source and adjust command line options.

The old libnfsidmap2 package unfortunately has an incorrect major
number, it should have been libnfsidmap0 (the library it carries is
.so.0.3.0 and has a soname of 0). Maybe there is some history behind
this. That creates the odd situation now with the new one, which is
libnfsidmap1. Reminds me of the pcre2/pcre3 situation, where pcre2 is
newer.

There is a new service, nfsdcld, a client tracking daemon, used in
NFSv4. It's just an upgrade from what was called "legacy tracking" in
old kernels, then got replaced by "nfsdcltrack", but that one isn't
container-friendly, and now we have nfsdcld.

NFS, as usual, has many intertwined services, and I'm just happy that
all the systemd units seem to have correct declarations and that it
"just works", so far at least in my testing. But corner cases are for
sure there somewhere. I tested one, where nfs was exporting an iscsi
mounted filesystem, and in older versions that would hang the boot of
the server, but that worked, phew. That sounded exactly like a "corner
case".

Finally, the reverse dependencies need to be rebuilt and checked that
they still work. In Ubuntu, that's nfs-ganesha and sssd, and they at
least build, I haven't checked Debian.

So, my summary:
- it's my opinion that debian and ubuntu need the new version sooner
rather than later. I'm actively working on bringing it into ubuntu,
based on the exp package from debian. My branch is currently at [10],
with a PPA at [11]. The delta we had was basically zeroed, due to a
combination of upstream changes and debian changes.
- we need a plan for an upgrade path. Some choices:
  - do nothing but release notes
  - detect if /etc/default/nfs-* have changes, and warn in that case,
asking the user to move the changes over to /etc/nfs.conf
  - to help with above, also ship fedora's script and let the user
know it exists and could be used. Maybe even run it and place the
output somewhere temporary for analysis
  - actually run fedora's conversion script in postinst, and let the
user know it was done and ask them to double check
- old source packages (src:libnfsidmap and src:libnfsidmap-regex) need
to be removed/obsoleted. I think it's safe to say upstream libnfsidmap
is gone, but libnfsidmap-regex still seems active. We *could* just not
build nfs-utils's regex plugin, and use src:libnfsidmap-regex, but the
libnfsidmap history has shown that at least in that case, nfs-utils'
implementation has diverged over time.

Cheers!


1. https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1878601
2. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=1ea6d9231f839b968adb44eaf98b363f436cb1d5
3. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461
4. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=d77ee0f18c0e0658f892932600c38c346c4d5337
5. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=1699fc34fe74ceda67e45453890a654c59f2b9e3
6. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=2662e1ba98707014b6167e1e5bd3162d6d8f52af
7. https://src.fedoraproject.org/rpms/nfs-utils/blob/rawhide/f/nfsconvert.py
8. https://src.fedoraproject.org/rpms/nfs-utils/blob/rawhide/f/nfs-convert.service
9. https://code.launchpad.net/~ahasenack/+git/nfsconvert
10. https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils
11. https://launchpad.net/~ahasenack/+archive/ubuntu/nfs-utils-merge/

[toc] | [prev] | [next] | [standalone]

#74383 — Bug#1005236: closing 1005236

Hi,

On Thu, Feb 10, 2022 at 08:13:12PM +0800, Tongliang Liao wrote:
> I'm aware of the exp version, but there're 2 concerns:
> 
>    1. Deploying from exp repo doesn't sound right for production systems,
>    for stability reason of course.
>    2. I'm not familiar of changes in nfs-utils. Given the major version
>    update and the fact that both Debian 11/Sid haven't included v2, I
>    guess it's either not well-tested on Debian, or has breaking changes that
>    most people don't want? That's why I proposed for a simple backport,
>    although most non-Debian distros have moved to v2 officially.

Let me explain, because I realize the just closing the bug might be
missinterpreted. This was for version tracking. The issue is fixed in
the repsective experimental version, so we can track it accordingly.
The BTS will show you still affected the unstable, testing and stable
version.

We "might" backport the fix to stable, once it is fixed in the upper
suite that said, and yes the target would then be to cherry-pick the
commit you referenced. Moving to 2.5.4 in stable is not an option.

So far we got only little feedback on the experimental version, so we
were not yet confident to upload it to unstable. But we need to move
this move earlier than too late for bookworm to avoid that we have
another Debian cycle with an ancient nfs-utils version.

There is as well an open question on how to handle the upstream
introduced move to /etc/nfs.conf.

Hope this clarifies your questions.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#74384 — Bug#1005236: closing 1005236

[Multipart message — attachments visible in raw view] — view raw

Aha thanks for the clarification, that closing is definitely misleading.

> So far we got only little feedback on the experimental version, so we
were not yet confident to upload it to unstable.

One possible option for feedback is to have it in Sid and let Ubuntu
quickly try it out on non-LTS, they certainly have enough community for
this.
As long as it's stabilized before the LTS cut, it should be good for
everyone.

On Thu, Feb 10, 2022 at 9:27 PM Salvatore Bonaccorso <carnil@debian.org>
wrote:

> Hi,
>
> On Thu, Feb 10, 2022 at 08:13:12PM +0800, Tongliang Liao wrote:
> > I'm aware of the exp version, but there're 2 concerns:
> >
> >    1. Deploying from exp repo doesn't sound right for production systems,
> >    for stability reason of course.
> >    2. I'm not familiar of changes in nfs-utils. Given the major version
> >    update and the fact that both Debian 11/Sid haven't included v2, I
> >    guess it's either not well-tested on Debian, or has breaking changes
> that
> >    most people don't want? That's why I proposed for a simple backport,
> >    although most non-Debian distros have moved to v2 officially.
>
> Let me explain, because I realize the just closing the bug might be
> missinterpreted. This was for version tracking. The issue is fixed in
> the repsective experimental version, so we can track it accordingly.
> The BTS will show you still affected the unstable, testing and stable
> version.
>
> We "might" backport the fix to stable, once it is fixed in the upper
> suite that said, and yes the target would then be to cherry-pick the
> commit you referenced. Moving to 2.5.4 in stable is not an option.
>
> So far we got only little feedback on the experimental version, so we
> were not yet confident to upload it to unstable. But we need to move
> this move earlier than too late for bookworm to avoid that we have
> another Debian cycle with an ancient nfs-utils version.
>
> There is as well an open question on how to handle the upstream
> introduced move to /etc/nfs.conf.
>
> Hope this clarifies your questions.
>
> Regards,
> Salvatore
>


-- 
From  LTL

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web