Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753168AbbHRXo3 (ORCPT ); Tue, 18 Aug 2015 19:44:29 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:49564 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753098AbbHRXo0 (ORCPT ); Tue, 18 Aug 2015 19:44:26 -0400 Date: Tue, 18 Aug 2015 16:44:25 -0700 From: Andrew Morton To: Dongsu Park Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Peter Hurley , Josh Triplett , Al Viro , David Howells , Alban Crequy Subject: Re: [PATCH v2] devpts: allow mounting with uid/gid of uint32_t Message-Id: <20150818164425.76b9df40f94bbd2a57d0d518@linux-foundation.org> In-Reply-To: <692839ff7158dbb96dd20ce8e36c13f85fa64fd7.1439910753.git.dpark@posteo.net> References: <882a878038efb5fed381be5d4817ff44d90703d5.1439904209.git.dpark@posteo.net> <692839ff7158dbb96dd20ce8e36c13f85fa64fd7.1439910753.git.dpark@posteo.net> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2254 Lines: 70 On Tue, 18 Aug 2015 17:18:19 +0200 Dongsu Park wrote: > To allow devpts to be mounted with options of uid/gid of uint32_t, > use kstrtouint() instead of match_int(). Doing that, mounting devpts > with uid or gid > (2^31 - 1) will work as expected, e.g.: > > # mount -t devpts devpts /tmp/devptsdir -o \ > newinstance,ptmxmode=0666,mode=620,uid=3598450688,gid=3598450693 > > It was originally by reported on systemd github issues: > https://github.com/systemd/systemd/issues/956 > > --- a/fs/devpts/inode.c > +++ b/fs/devpts/inode.c > @@ -188,23 +188,35 @@ static int parse_mount_options(char *data, int op, struct pts_mount_opts *opts) > token = match_token(p, tokens, args); > switch (token) { > case Opt_uid: > - if (match_int(&args[0], &option)) > + { It might be neater to lay this out as case Opt_uid: { > + char *uidstr = args[0].from; > + uid_t uidval; > + int rc = kstrtouint(uidstr, 0, &uidval); This assumes that the architecture/config uses a uint for uid_t. We have no business assuming this - it's an opaque type for a reason. It would be safer to do unsigned long uidl; rc = kstrtoul(uidstr, 0, &uidl); uidval = uidl; > + if (rc) > return -EINVAL; I don't get it. From my reading, kstrtouint->parse_integer() returns "number of characters parsed or -E". So this code won't work. But presumably it *does* work, so why? Also, we should probably return `rc' here if it's negative, to propagate the error which kstrtouint() detected. That's a minor non-back-compatible change but it shouldn't matter. otoh, kstrtouint() likes to return -ERANGE when things go wrong. ERANGE means "Math result not representable", which is a nonsenscal error code in this context. Sigh, why do people keep doing this. > - uid = make_kuid(current_user_ns(), option); > + uid = make_kuid(current_user_ns(), uidval); > if (!uid_valid(uid)) > return -EINVAL; > opts->uid = uid; > opts->setuid = 1; > break; > > ... > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/