Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2783148ybl; Mon, 19 Aug 2019 07:28:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqykrBozFqJAxcCA9McTl/X9MVPEhgoX3f4hnjrMv0dNeVU6GSOblymHkC6pzNeA9H4NOS+H X-Received: by 2002:a17:902:5a1:: with SMTP id f30mr23163168plf.64.1566224928684; Mon, 19 Aug 2019 07:28:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566224928; cv=none; d=google.com; s=arc-20160816; b=EqhHyGFmXvkcxZpXAmRs+ZlVBNFXMthrjPsBzzQp45KDVOR0DSPPB66DGM9WOFNx94 E1iNuRJAFRiZkC5oPjY9xidSbJLQBF7M3enkamHssljW9xWqa8AVQVaU+U4xbnEfrrkO DyMd7xX9GF2ITomTf4s9nRnPsCeoWBqqYBu/AandCEvgeV1o3pxS8/G/j1S4QQXQV+0T CMaCiCBo/A/SVlWphHEwaMJhTuUFlzrkuIoODomlsMMP7BcXPiNypDfoxvp9UOJCu3d7 ixnxzGF/FYQ3jUCDnB6s68aQg4TSmijoej7TnruOZECw3avSeThbF0t/ohbqFW4pr3v6 wAtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature; bh=R8P35k0UQJjogiM45vdQN2jnqatZkqahOot8zhEBvOA=; b=OCgyQCzTnxfsaxRVK2J18s4bRd9U06BWSFzhmiF/Tn1SKgCO+o0JslVGaAa9RcBeD8 djdDgCVchzCSPKBdPJURBO0uhteDJEXnl9MoZsHKQFvhCiu6fepVZ/JvWtBNISuNGDtc v3uwYg7aJIZ7gBRA+9jdID4I4HkFeewLuMa5PLRR7DhQe9wtUWl0iG2ZzQCFohbvhlA3 Js8z0Xt3MjTtQB/2Yq2O+MxLnD/yMB5IKZPN3VECzA0Ij6ZawE6nxHdTyhJZRp3CmObu MoUAVc/uBd6RJgslwEESP4pRRHLoVPCH56Z55JV4dnVpWOvb9Q6pATOWVvZl6v4PO/2I qZaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@digidescorp.com header.s=google header.b=C71yn3O+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t1si8886817pjy.39.2019.08.19.07.28.33; Mon, 19 Aug 2019 07:28:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@digidescorp.com header.s=google header.b=C71yn3O+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726769AbfHSO1Z (ORCPT + 99 others); Mon, 19 Aug 2019 10:27:25 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:39950 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726553AbfHSO1Z (ORCPT ); Mon, 19 Aug 2019 10:27:25 -0400 Received: by mail-io1-f67.google.com with SMTP id t6so4670057ios.7 for ; Mon, 19 Aug 2019 07:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digidescorp.com; s=google; h=from:to:cc:subject:date:message-id; bh=R8P35k0UQJjogiM45vdQN2jnqatZkqahOot8zhEBvOA=; b=C71yn3O+tVUgGp34iebMxBFlEYKY5R6egz+a8nPwjIFrrYZQj7NEkmJqILHXVNuraV z8sBN3M48RWzPbmVV4YXWyfLOs6kUmC5mvGoo325X+Wg3P6oEeOohxk4DMM2l+TTVJfr MihiKb+FShaUp9U93XS/AZ0LRPlZm4pWd4n5k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=R8P35k0UQJjogiM45vdQN2jnqatZkqahOot8zhEBvOA=; b=HoW/DEZQ6eI5g44RVxMOMJSwAYWkHvy2TrH48Sjr2aD5o820y6TzNdfqCSGb+reihm XBgwd3U3R/aeG3vj2kmZ4C20c++RfMy+aGFjr8wSXMV44k+AgwWAWBt9XapHFHkLzohe N6izrHEwG0nqxi/wH5RqtgGLPrRBKihFP+kG5OptJFTl0XLQHxaOuwQ1zgpCzlMwryug Gm0/spxnYoUDz66sXippJ5PSAQWJpikK66ny8DzFB4xSPzjmj+dM9m46GVTGeTD/gND0 fECUQ2kMVCfJ1Kv6AIXEjHRaxWHogD9HVmI3ADCz6jLgLA94NK5RAl/LbS+6zXteQXAl Q3vA== X-Gm-Message-State: APjAAAUf+BTR1k4sEomx0hw/Kc4AKFpqKVWFDrihBr8FUy0STFkuzn6f V8iluiBNcRErO+ADYBFgr236gA== X-Received: by 2002:a02:4005:: with SMTP id n5mr27068009jaa.73.1566224844827; Mon, 19 Aug 2019 07:27:24 -0700 (PDT) Received: from iscandar.digidescorp.com (104-51-28-62.lightspeed.cicril.sbcglobal.net. [104.51.28.62]) by smtp.googlemail.com with ESMTPSA id v10sm16487537iob.43.2019.08.19.07.27.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Aug 2019 07:27:24 -0700 (PDT) From: "Steven J. Magnani" X-Google-Original-From: "Steven J. Magnani" To: Jan Kara Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Steven J . Magnani" Subject: [PATCH] udf: augment owner permissions on new inodes Date: Mon, 19 Aug 2019 09:27:07 -0500 Message-Id: <20190819142707.18070-1-steve@digidescorp.com> X-Mailer: git-send-email 2.17.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Windows presents files created within Linux as read-only, even when permissions in Linux indicate the file should be writable. UDF defines a slightly different set of basic file permissions than Linux. Specifically, UDF has "delete" and "change attribute" permissions for each access class (user/group/other). Linux has no equivalents for these. When the Linux UDF driver creates a file (or directory), no UDF delete or change attribute permissions are granted. The lack of delete permission appears to cause Windows to mark an item read-only when its permissions otherwise indicate that it should be read-write. Fix this by granting UDF delete and change attribute permissions to the owner when creating a new inode. Reported by: Ty Young Signed-off-by: Steven J. Magnani --- --- a/fs/udf/udf_i.h 2019-08-14 07:24:05.029508342 -0500 +++ b/fs/udf/udf_i.h 2019-08-19 08:55:37.797394177 -0500 @@ -38,6 +38,7 @@ struct udf_inode_info { __u32 i_next_alloc_block; __u32 i_next_alloc_goal; __u32 i_checkpoint; + __u32 i_extraPerms; unsigned i_alloc_type : 3; unsigned i_efe : 1; /* extendedFileEntry */ unsigned i_use : 1; /* unallocSpaceEntry */ --- a/fs/udf/ialloc.c 2019-08-14 07:24:05.029508342 -0500 +++ b/fs/udf/ialloc.c 2019-08-19 08:33:08.992422457 -0500 @@ -118,6 +118,7 @@ struct inode *udf_new_inode(struct inode iinfo->i_lenAlloc = 0; iinfo->i_use = 0; iinfo->i_checkpoint = 1; + iinfo->i_extraPerms = FE_PERM_U_DELETE | FE_PERM_U_CHATTR; if (UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_USE_AD_IN_ICB)) iinfo->i_alloc_type = ICBTAG_FLAG_AD_IN_ICB; else if (UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_USE_SHORT_AD)) --- a/fs/udf/inode.c 2019-08-14 07:24:05.029508342 -0500 +++ b/fs/udf/inode.c 2019-08-19 08:42:46.537530051 -0500 @@ -45,6 +45,10 @@ #define EXTENT_MERGE_SIZE 5 +#define FE_MAPPED_PERMS (FE_PERM_U_READ | FE_PERM_U_WRITE | FE_PERM_U_EXEC | \ + FE_PERM_G_READ | FE_PERM_G_WRITE | FE_PERM_G_EXEC | \ + FE_PERM_O_READ | FE_PERM_O_WRITE | FE_PERM_O_EXEC) + static umode_t udf_convert_permissions(struct fileEntry *); static int udf_update_inode(struct inode *, int); static int udf_sync_inode(struct inode *inode); @@ -1458,6 +1462,8 @@ reread: else inode->i_mode = udf_convert_permissions(fe); inode->i_mode &= ~sbi->s_umask; + iinfo->i_extraPerms = le32_to_cpu(fe->permissions) & ~FE_MAPPED_PERMS; + read_unlock(&sbi->s_cred_lock); link_count = le16_to_cpu(fe->fileLinkCount); @@ -1691,10 +1697,7 @@ static int udf_update_inode(struct inode ((inode->i_mode & 0070) << 2) | ((inode->i_mode & 0700) << 4); - udfperms |= (le32_to_cpu(fe->permissions) & - (FE_PERM_O_DELETE | FE_PERM_O_CHATTR | - FE_PERM_G_DELETE | FE_PERM_G_CHATTR | - FE_PERM_U_DELETE | FE_PERM_U_CHATTR)); + udfperms |= iinfo->i_extraPerms; fe->permissions = cpu_to_le32(udfperms); if (S_ISDIR(inode->i_mode) && inode->i_nlink > 0)