First, don't bother trying to check file permissions. The only real way to check file permissions is when you try the actual operation. So check for failure and report a good error message.

You might see advice to use access() to check permissions but that is a bit of a misleading API. It was never meant for checking generic file permissions. It was meant only for use by set-UID programs to make a rough guess about whether the file would be accessible by the user once set-UID was taken away. And it only gives a rough guess, ignoring lots of potential reasons for an access to fail or succeed.

Second, the way you talk about this checking makes it sound like you are just going to generate a bunch of race conditions. For example, checking whether a file exists, say with -e, before attempting to overwrite causes a race condition. Instead, open the file in a way that will fail if the file exists then you can check if the file existing is what caused the open to fail and deal with it at that point.

But if, for example, your desired behavior to avoid overwriting a file is to rename the current file before opening the new one, then you still need to open the new file in a way that will fail if the file already exists or you get a race condition again.

The symlink trick only works when a privileged program (such as a set-UID program) keeps its privileges while working with files in a directory that it doesn't need its privileges for (such as /tmp). Because if you can use a symlink to redirect non-/tmp files, then you have privilege to just directly move the file and don't need a symlink trick.

A much better solution than checking for symlinks is to have your set-UID program remove its privileges whenever it deals with places where it doesn't need them.

I don't think checking for tricky things is usually a good idea. If your program isn't set-UID (or privileged in some other way), then these tricks really don't pose a security hole and may actually be used legitimately to work-around some temporary system problem.

But even if there are no security issues to worry about, it is a good idea to avoid race conditions.

        - tye (but my friends call me "Tye")

In reply to (tye)Re: is I/O checking worth it? by tye
in thread is I/O checking worth it? by Beatnik

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.