All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Joe Perches" <joe@perches.com>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"David Howells" <dhowells@redhat.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	linux-afs@lists.infradead.org,
	"Pali Rohár" <pali.rohar@gmail.com>,
	"Alexey Dobriyan" <adobriyan@gmail.com>
Subject: Re: [PATCH] afs: proc cells and rootcell are writeable
Date: Tue, 28 Jan 2014 13:20:48 +0100	[thread overview]
Message-ID: <20140128122048.GA26767@gmail.com> (raw)
In-Reply-To: <CAMuHMdXciS54ZZA2TV3+JZP7szHyGOhbrdQ_1rEYUwx2YSO+Qg@mail.gmail.com>


* Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> On Tue, Jan 28, 2014 at 1:04 PM, Ingo Molnar <mingo@kernel.org> wrote:
> > * Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >> On Sun, Jan 26, 2014 at 9:25 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >> > * Ingo Molnar <mingo@kernel.org> wrote:
> >> >> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >> >> > On Sun, Jan 26, 2014 at 4:27 AM, David Howells <dhowells@redhat.com> wrote:
> >> >> > > -       p = proc_create("cells", 0, proc_afs, &afs_proc_cells_fops);
> >> >> > > +       p = proc_create("cells", S_IFREG | S_IRUGO | S_IWUSR, proc_afs, &afs_proc_cells_fops);
> >> >> > > -       p = proc_create("rootcell", 0, proc_afs, &afs_proc_rootcell_fops);
> >> >> > > +       p = proc_create("rootcell", S_IFREG | S_IRUGO | S_IWUSR, proc_afs, &afs_proc_rootcell_fops);
> >> >> >
> >> >> > So the S_IFREG isn't necessary.
> >> >> >
> >> >> > And quite frankly, I personally think S_IRUGO | S_IWUSR is _less_
> >> >> > readable than 0644. It's damn hard to parse those random letter
> >> >> > combinations, and at least I have to really think about it, in a way
> >> >> > that the octal representation does *not* make me go "I have to think
> >> >> > about that".
> >> >> >
> >> >> > So my personal preference would be to just see that simple 0644 in
> >> >> > proc_create. Hmm?
> >> >>
> >> >> Perhaps we could also generate the most common variants as:
> >> >>
> >> >>  #define PERM__rw_r__r__              0644
> >> >>  #define PERM__r________              0400
> >> >>  #define PERM__r__r__r__              0444
> >> >>  #define PERM__r_xr_xr_x              0555
> >>
> >> I like it (also without the PERM prefix, cfr. Alexey's old patch).
> >>
> >> >> or something similar, more or less matching the output of 'ls -l'?
> >> >
> >> > Another variant of this would be to do the following macro:
> >> >
> >> >         PERM(R_X, R_X, R_X)
> >> >         PERM(R__, R__, R__)
> >> >         PERM(RW_, R__, R__)
> >>
> >> IMHO, this is again less outstanding.
> >>
> >> > With the advantage of separating the groups better and reducing the
> >> > number of constants needed.
> >>
> >> Only a limited number of combinations is in active use, right?
> >
> > Correct - and in fact that kind of limitation is also a security
> > feature: using patterns _outside_ of the typical, already defined
> > group of permission patterns would in itself be a 'is that really
> > justified?' red flag during review.
> 
> Then Joe (CCed :-) can write a checkpatch rule to flag all new users of the
> I_S[RWX}* flags..,

I'd also flag raw octal use: they are easily mixed up and only a 
relatively small group of people will read them as-is, most other 
kernel/Linux people will only recognize anomalies in the rwxrwxrwx 
notation.

So the number of reviewers who might spot bugs, either during patch 
submission or later on reading the code increases.

Thanks,

	Ingo

  reply	other threads:[~2014-01-28 12:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-26 12:27 [PATCH] afs: proc cells and rootcell are writeable David Howells
2014-01-26 19:23 ` Linus Torvalds
2014-01-26 20:19   ` Ingo Molnar
2014-01-26 20:22     ` Ingo Molnar
2014-01-26 20:25     ` Ingo Molnar
2014-01-28  8:39       ` Geert Uytterhoeven
2014-01-28 12:04         ` Ingo Molnar
2014-01-28 12:17           ` Geert Uytterhoeven
2014-01-28 12:20             ` Ingo Molnar [this message]
2014-01-28 17:34             ` Joe Perches
2014-01-28 20:20   ` David Howells
2014-01-28 20:27     ` Al Viro
2014-01-28 20:56       ` David Howells
2014-01-30 21:48 ` Eric W. Biederman
2014-01-30 21:50   ` Linus Torvalds
2014-01-30 22:15     ` Pali Rohár
2014-01-30 22:27       ` Linus Torvalds
2014-01-30 22:36         ` Dave Jones
2014-01-30 22:33       ` Russ Allbery
2014-01-31  0:21     ` David Howells
2014-01-31  0:28       ` David Howells
2014-01-31  0:31         ` David Howells
2014-01-31  0:07   ` David Howells
2014-01-31  0:20     ` David Howells
  -- strict thread matches above, loose matches on Subject: below --
2014-01-27 12:33 Alexey Dobriyan
2013-11-20 13:30 Pali Rohár
2013-12-10  8:02 ` Pali Rohár
2013-12-16  7:00 ` Andrew Morton
2013-12-17 13:19   ` Pali Rohár
2013-12-17 18:31   ` David Howells
2013-12-31  9:59     ` Pali Rohár

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140128122048.GA26767@gmail.com \
    --to=mingo@kernel.org \
    --cc=adobriyan@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=geert@linux-m68k.org \
    --cc=joe@perches.com \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pali.rohar@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.