NetBSD Problem Report #53987

From www@NetBSD.org  Sun Feb 17 14:42:01 2019
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 816617A151
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 17 Feb 2019 14:42:01 +0000 (UTC)
Message-Id: <20190217144200.571727A1EC@mollari.NetBSD.org>
Date: Sun, 17 Feb 2019 14:42:00 +0000 (UTC)
From: paulrenke.mohr@stud.tu-darmstadt.de
Reply-To: paulrenke.mohr@stud.tu-darmstadt.de
To: gnats-bugs@NetBSD.org
Subject: smbfs can't remove files when run in a rump kernel
X-Send-Pr-Version: www-1.0

>Number:         53987
>Category:       misc
>Synopsis:       smbfs can't remove files when run in a rump kernel
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 17 14:45:00 +0000 2019
>Originator:     Paul Mohr
>Release:        NetBSD 7.1.1
>Organization:
TU Darmstadt
>Environment:
NetBSD kernelbuilder 7.1.1 NetBSD 7.1.1 (GENERIC.201712222334Z) amd64
>Description:
After mounting an smb share (residing on the linux host of the qemu VM running netbsd) using rump_smbfs, attempting to remove any file on that share results in the error message "Operation not permitted".

This is due to a failed check in /usr/src/sys/fs/smbfs/smbfs_vnops.c 's smbfs_remove() function: In the section (634 following)

if (vp->v_type == VDIR || (np->n_flag & NOPEN) != 0
    || vp->v_usecount != 1){
	/* XXX Eventually should do something along NFS sillyrename */
	error = EPERM;
}else {
	smb_makescred(&scred, curlwp, cnp->cn_cred);
	error = smbfs_smb_delete(np, &scred);
}

vp->v_usecount will read 2 (rather than 1) during normal operation. error is then set to EPERM (1) and the actual deletion of the file (in the else) never takes place.

Moving files within the mounted file systems will not trigger this bug, but moving files onto another filesystem will.

The smbfs code does not appear to have been meaningfully changed since 2017, so I assume that the problem persists in newer releases.
>How-To-Repeat:
kernelbuilder# mount -o rump -t smbfs //smbusr@LNX-HOST/samba /mnt  #Mount some share to /mnt
kernelbuilder# cp testfile /mnt/test  #copy some file onto the share (optional)
kernelbuilder# rm /mnt/test  #attempt to remove that file (or any preexisting file)
rm: /mnt/test: Operation not permitted

(LNX-HOST/samba is a valid samba share smbusr can rw-access; the password of smbusr is locally cached in the ~/.nsmbrc file.)
>Fix:
Trivially, changing the last condition of the if statement to 

vp->v_usecount != 2

and recompiling the smbfs rumplib will re-allow the deletion of files.
This change would need to be reversed to compile working smbfs kernel modules and does not address the underlying issue of the incorrect value stored in v_usecount.

Home	PR Database Search