unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Thien-Thi Nguyen <ttn@gnuvola.org>
To: guile-devel@gnu.org
Subject: Re: port-filename and path canonicalization
Date: Wed, 21 Apr 2010 21:16:30 +0200	[thread overview]
Message-ID: <87aaswd3ap.fsf@ambire.localdomain> (raw)
In-Reply-To: <87mxwxjim6.fsf@gnu.org> ("Ludovic Courtès"'s message of "Wed, 21 Apr 2010 10:49:05 +0200")

() ludo@gnu.org (Ludovic Courtès)
() Wed, 21 Apr 2010 10:49:05 +0200

   I think open file ports shouldn’t grant any authority beyond
   access to the open file.  Just like an open file descriptor
   doesn’t convey any authority beyond access to the underlying
   file (if we omit ‘..’ lookups on a directory file descriptor
   with openat(3)).

I agree (and was about to cite openat(3) et al -- glad you
beat me to it!), but that's neither here nor there:

Whether or not the authority associated with the containing
directory is user-visible is a design detail of the directory
object.  (More information need not imply more access.)

That is, if a file port supports ‘file-port-directory’, then how
to use/restrict the resulting object is left up to higher layers,
where it belongs.

Reifying directories is good for both security and efficiency.
Why chase symlinks and {l}stat(2) more than necessary?

thi




  reply	other threads:[~2010-04-21 19:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19 14:52 file names embedded in .go Andy Wingo
2010-04-19 21:46 ` Thien-Thi Nguyen
2010-04-20  0:08   ` Jose A. Ortega Ruiz
2010-04-20 11:35     ` Thien-Thi Nguyen
2010-04-20 19:15       ` Jose A. Ortega Ruiz
2010-04-21  7:45         ` Thien-Thi Nguyen
2010-04-20  9:45   ` Andy Wingo
2010-04-20 10:34     ` Thien-Thi Nguyen
2010-04-19 23:12 ` port-filename and path canonicalization Ludovic Courtès
2010-04-20  9:42   ` Andy Wingo
2010-04-20 11:15     ` Thien-Thi Nguyen
2010-04-21  8:49       ` Ludovic Courtès
2010-04-21 19:16         ` Thien-Thi Nguyen [this message]
2010-04-21 22:26           ` Ludovic Courtès
2010-04-22  7:42             ` Thien-Thi Nguyen
2010-04-20 16:57     ` Ludovic Courtès
2010-04-22 11:10       ` Andy Wingo
2010-04-22 12:50         ` Ludovic Courtès
2010-04-19 23:23 ` file names embedded in .go Ludovic Courtès

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

  List information: https://www.gnu.org/software/guile/

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

  git send-email \
    --in-reply-to=87aaswd3ap.fsf@ambire.localdomain \
    --to=ttn@gnuvola.org \
    --cc=guile-devel@gnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).