Bug#934160: marked as done (NFSv4.2: umask not applied on filesystem without ACL support)

2020-07-10 Thread Debian Bug Tracking System
Your message dated Fri, 10 Jul 2020 20:10:09 +
with message-id 
and subject line Bug#962254: fixed in linux 4.19.131-1
has caused the Debian Bug report #962254,
regarding NFSv4.2: umask not applied on filesystem without ACL support
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
962254: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962254
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: nfs-common
Version: 1:1.3.4-2.5
Severity: grave
Tags: security
Justification: user security hole

I have an NFS client and server both running Debian.  I recently
upgraded them both to buster.

I discovered today that the regular process umask has been ignored on
my nfs mounts since the upgrade, and all files and directories are
being created a+rw.

On the client, the fstab fstype is nfs4 and the mount options are
hard,intr,bg,noatime.  The relevant datasets are exported
rw,no_root_squash,no_subtree_check from the server.

In researching this, I stumbled across
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736 and
https://bugzilla.redhat.com/show_bug.cgi?id=1667761 which indicate the
problem is present elsewhere as well.  Adding vers=4.1 to my client's
mount options completely resolved the problem.  (Though now I have a
couple weeks' worth of files with unintentionally open permissions to
wade through.)

I tagged this as security and grave because it opens up quite a few
scenarios for users to receive privileges they shouldn't, and for
other potential mischief (placing malicious executables in
world-writable directories, etc).

The server is indeed running zfs with its default acltype setting
(off).  As the Ubuntu bug report shows, mounting with noacl doesn't
resolve the behavior either.  The RedHat bug occurred with an OpenWRT
server, unlikely to be running zfs.  I do not believe this bug should
be pinned down to ZFS; a filesystem not supporting ACLs should not
result in umask 0 for all clients in any scenario.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nfs-common depends on:
ii  adduser 3.118
ii  keyutils1.6-6
ii  libc6   2.28-10
ii  libcap2 1:2.25-2
ii  libcom-err2 1.44.5-1
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libevent-2.1-6  2.1.8-stable-4
ii  libgssapi-krb5-21.17-3
ii  libk5crypto31.17-3
ii  libkeyutils11.6-6
ii  libkrb5-3   1.17-3
ii  libmount1   2.33.1-0.1
ii  libnfsidmap20.25-5.1
ii  libtirpc3   1.1.4-0.4
ii  libwrap07.6.q-28
ii  lsb-base10.2019051400
ii  rpcbind 1.2.5-0.3
ii  ucf 3.0038+nmu1

Versions of packages nfs-common recommends:
ii  python  2.7.16-1

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: linux
Source-Version: 4.19.131-1
Done: Salvatore Bonaccorso 

We believe that the bug you reported is fixed in the latest version of
linux, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 962...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Salvatore Bonaccorso  (supplier of updated linux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive

Bug#934160: marked as done (NFSv4.2: umask not applied on filesystem without ACL support)

2020-06-25 Thread Debian Bug Tracking System
Your message dated Thu, 25 Jun 2020 10:00:16 +
with message-id 
and subject line Bug#962254: fixed in linux 5.7.6-1
has caused the Debian Bug report #962254,
regarding NFSv4.2: umask not applied on filesystem without ACL support
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
962254: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962254
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: nfs-common
Version: 1:1.3.4-2.5
Severity: grave
Tags: security
Justification: user security hole

I have an NFS client and server both running Debian.  I recently
upgraded them both to buster.

I discovered today that the regular process umask has been ignored on
my nfs mounts since the upgrade, and all files and directories are
being created a+rw.

On the client, the fstab fstype is nfs4 and the mount options are
hard,intr,bg,noatime.  The relevant datasets are exported
rw,no_root_squash,no_subtree_check from the server.

In researching this, I stumbled across
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736 and
https://bugzilla.redhat.com/show_bug.cgi?id=1667761 which indicate the
problem is present elsewhere as well.  Adding vers=4.1 to my client's
mount options completely resolved the problem.  (Though now I have a
couple weeks' worth of files with unintentionally open permissions to
wade through.)

I tagged this as security and grave because it opens up quite a few
scenarios for users to receive privileges they shouldn't, and for
other potential mischief (placing malicious executables in
world-writable directories, etc).

The server is indeed running zfs with its default acltype setting
(off).  As the Ubuntu bug report shows, mounting with noacl doesn't
resolve the behavior either.  The RedHat bug occurred with an OpenWRT
server, unlikely to be running zfs.  I do not believe this bug should
be pinned down to ZFS; a filesystem not supporting ACLs should not
result in umask 0 for all clients in any scenario.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nfs-common depends on:
ii  adduser 3.118
ii  keyutils1.6-6
ii  libc6   2.28-10
ii  libcap2 1:2.25-2
ii  libcom-err2 1.44.5-1
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libevent-2.1-6  2.1.8-stable-4
ii  libgssapi-krb5-21.17-3
ii  libk5crypto31.17-3
ii  libkeyutils11.6-6
ii  libkrb5-3   1.17-3
ii  libmount1   2.33.1-0.1
ii  libnfsidmap20.25-5.1
ii  libtirpc3   1.1.4-0.4
ii  libwrap07.6.q-28
ii  lsb-base10.2019051400
ii  rpcbind 1.2.5-0.3
ii  ucf 3.0038+nmu1

Versions of packages nfs-common recommends:
ii  python  2.7.16-1

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: linux
Source-Version: 5.7.6-1
Done: Salvatore Bonaccorso 

We believe that the bug you reported is fixed in the latest version of
linux, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 962...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Salvatore Bonaccorso  (supplier of updated linux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive