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
| ||
|
Message-Id: <E6355B76-4796-4AFE-B971-CC544331DEB8@dilger.ca> Date: Fri, 18 Sep 2015 14:36:34 -0600 From: Andreas Dilger <adilger@...ger.ca> To: Mike Frysinger <vapier@...too.org> Cc: "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org> Subject: Re: [PATCH e2fsprogs] subst: use 0644 perms On Sep 18, 2015, at 12:08 PM, Mike Frysinger <vapier@...too.org> wrote: > > On 18 Sep 2015 10:52, Andreas Dilger wrote: >> On Sep 18, 2015, at 01:54, Mike Frysinger <vapier@...too.org> wrote: >>> When running on NFS, opening files with 0444 perms for writing can >>> sometimes fail. Since there's no real reason for these files to be >>> read-only, give the owner write permission. >> >> Actually, there IS a reason for subst to make these files read-only. They are auto-generated and any edits to these files can be overwritten and lost if their origin files are modified. >> >> I'd lost edits to these auto generated files many time because they are the ones that "tags" or "cscope" will jump to when searching for symbols. >> >> There really isn't any reason for them to be writable, so the fact that you are getting an error trying to open them for writing is a hint that you are doing, or going to do, the wrong thing and the read-only nature of the file is preventing you from going down the wrong path. > > I think you misread my report. this has nothing to do with people > trying to modify the files after the fact. NFS can (and sometimes > does) throw an error at the time of the *open* call even if the file > doesn't exist. Seems like a bug in NFS. At least I know the POSIX test suite requires that to work (we had similar problems with Lustre that had to be fixed many years ago). In fact, there is a special check for this in knfsd: nfsd_permission(struct svc_rqst *rqstp, struct svc_export *exp, struct dentry *dentry, int acc) { : : /* * The file owner always gets access permission for accesses that * would normally be checked at open time. This is to make * file access work even when the client has done a fchmod(fd, 0). * * However, `cp foo bar' should fail nevertheless when bar is * readonly. A sensible way to do this might be to reject all * attempts to truncate a read-only file, because a creat() call * always implies file truncation. * ... but this isn't really fair. A process may reasonably call * ftruncate on an open file descriptor on a file with perm 000. * We must trust the client to do permission checking - using "ACCESS" * with NFSv3. */ if ((acc & NFSD_MAY_OWNER_OVERRIDE) && uid_eq(inode->i_uid, current_fsuid())) return 0; : : } Might be something that needs to be pursued with the kernel NFS folks? That said, I'm not against fixing subst so that it works on your system. > if you want to try to "protect" people, then it needs to be a chmod > after all the data has been written & closed. It that case, please update your patch to include something like: if (verbose) printf("Creating or replacing %s.\n", outfn); + /* Avoid accidentally editing generated file. */ + (void)fchmod(out, 0444); fclose(out); if (old) fclose(old); > this is how it used to > behave, but commit 2873927d15ffb9ee9ed0e2700791a0e519c715aa changed it. Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists