|
Packit |
1470ea |
|
|
Packit |
1470ea |
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" xmlns:xi="http://www.w3.org/2003/XInclude" type="topic" id="file-system" xml:lang="es">
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<info>
|
|
Packit |
1470ea |
<link type="guide" xref="index#specific-how-tos"/>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<credit type="author copyright">
|
|
Packit |
1470ea |
<name>Philip Withnall</name>
|
|
Packit |
1470ea |
<email its:translate="no">philip.withnall@collabora.co.uk</email>
|
|
Packit |
1470ea |
<years>2015</years>
|
|
Packit |
1470ea |
</credit>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<desc>Acceder al sistema de archivos</desc>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
|
|
Packit |
1470ea |
<mal:name>Daniel Mustieles</mal:name>
|
|
Packit |
1470ea |
<mal:email>daniel.mustieles@gmail.com</mal:email>
|
|
Packit |
1470ea |
<mal:years>2016</mal:years>
|
|
Packit |
1470ea |
</mal:credit>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
|
|
Packit |
1470ea |
<mal:name>Javier Mazorra</mal:name>
|
|
Packit |
1470ea |
<mal:email>mazi.debian@gmail.com</mal:email>
|
|
Packit |
1470ea |
<mal:years>2016</mal:years>
|
|
Packit |
1470ea |
</mal:credit>
|
|
Packit |
1470ea |
</info>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<title>Acceso al sistema de archivos</title>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<synopsis>
|
|
Packit |
1470ea |
<title>Resumen</title>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
There are a few anti-patterns to consider when accessing the file system.
|
|
Packit |
1470ea |
This article assumes knowledge of the standard
|
|
Packit |
1470ea |
<link href="https://developer.gnome.org/gio/stable/GFile.html">GFile </link>,
|
|
Packit |
1470ea |
<link href="https://developer.gnome.org/gio/stable/GInputStream.html">GInputStream </link>
|
|
Packit |
1470ea |
and
|
|
Packit |
1470ea |
<link href="https://developer.gnome.org/gio/stable/GOutputStream.html">GOutputStream </link>
|
|
Packit |
1470ea |
APIs.
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<list>
|
|
Packit |
1470ea |
<item>Use E/S asíncrona para acceder a archivos. (Consulte la <link xref="#asynchronous-io"/>) </item>
|
|
Packit |
1470ea |
<item>
|
|
Packit |
1470ea |
Always use appropriate functions to construct file names and paths.
|
|
Packit |
1470ea |
(<link xref="#file-path-construction"/>)
|
|
Packit |
1470ea |
</item>
|
|
Packit |
1470ea |
<item>
|
|
Packit |
1470ea |
Validate file paths are in the expected directories before using them.
|
|
Packit |
1470ea |
(<link xref="#path-validation-and-sandboxing"/>)
|
|
Packit |
1470ea |
</item>
|
|
Packit |
1470ea |
<item>
|
|
Packit |
1470ea |
Use mandatory access control profiles to enforce constraints on file
|
|
Packit |
1470ea |
access.
|
|
Packit |
1470ea |
(<link xref="#path-validation-and-sandboxing"/>)
|
|
Packit |
1470ea |
</item>
|
|
Packit |
1470ea |
</list>
|
|
Packit |
1470ea |
</synopsis>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<section id="asynchronous-io">
|
|
Packit |
1470ea |
<title>E/S asíncrona</title>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
Almost all I/O should be performed asynchronously. That is, without
|
|
Packit |
1470ea |
blocking the
|
|
Packit |
1470ea |
<link href="https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html">GLib
|
|
Packit |
1470ea |
main context</link>. This can be achieved by always using the
|
|
Packit |
1470ea |
*_async() and *_finish() variants of each I/O
|
|
Packit |
1470ea |
function.
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<example>
|
|
Packit |
1470ea |
Por ejempl, <link href="https://developer.gnome.org/gio/stable/GInputStream.html#g-input-stream-read-async">g_input_stream_read_async() </link> en lugar de <link href="https://developer.gnome.org/gio/stable/GInputStream.html#g-input-stream-read">g_input_stream_read() </link>.
|
|
Packit |
1470ea |
</example>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
Synchronous I/O blocks the main loop, which means that other events, such
|
|
Packit |
1470ea |
as user input, incoming networking packets, timeouts and idle callbacks,
|
|
Packit |
1470ea |
are not handled until the blocking function returns.
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
Synchronous I/O is acceptable in certain circumstances where the overheads
|
|
Packit |
1470ea |
of scheduling an asynchronous operation exceed the costs of local
|
|
Packit |
1470ea |
synchronous I/O on Linux. For example, making a small read from a local
|
|
Packit |
1470ea |
file, or from a virtual file system such as <file>/proc</file>. For such
|
|
Packit |
1470ea |
reads, the low level functions g_open() , read()
|
|
Packit |
1470ea |
and g_close() should be used rather than GIO.
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
Files in the user’s home directory do not count as local, as they
|
|
Packit |
1470ea |
could be on a networked file system.
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
Note that the alternative – running synchronous I/O in a separate thread –
|
|
Packit |
1470ea |
is highly discouraged; see the
|
|
Packit |
1470ea |
<link xref="threading#when-to-use-threading">threading guidelines</link>
|
|
Packit |
1470ea |
for more information.
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
</section>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<section id="file-path-construction">
|
|
Packit |
1470ea |
<title>Construcción de rutas de archivos</title>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
File names and paths are not normal strings: on some systems, they can use
|
|
Packit |
1470ea |
a character encoding other than UTF-8, while normal strings in GLib are
|
|
Packit |
1470ea |
guaranteed to always use UTF-8. For this reason, special functions should
|
|
Packit |
1470ea |
be used to build and handle file names and paths. (Modern Linux systems
|
|
Packit |
1470ea |
almost universally use UTF-8 for filename encoding, so this is not an
|
|
Packit |
1470ea |
issue in practice, but the file path functions should still be used for
|
|
Packit |
1470ea |
compatibility with systems such as Windows, which use UTF-16 filenames.)
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<example>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
For example, file paths should be built using
|
|
Packit |
1470ea |
<link href="https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-build-filename">g_build_filename() </link>
|
|
Packit |
1470ea |
rather than
|
|
Packit |
1470ea |
<link href="https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-strconcat">g_strconcat() </link>.
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
</example>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
Doing so makes it clearer what the code is meant to do, and also
|
|
Packit |
1470ea |
eliminates duplicate directory separators, so the returned path is
|
|
Packit |
1470ea |
canonical (though not necessarily absolute).
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<example>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
As another example, paths should be disassembled using
|
|
Packit |
1470ea |
<link href="https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-path-get-basename">g_path_get_basename() </link>
|
|
Packit |
1470ea |
and
|
|
Packit |
1470ea |
<link href="https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-path-get-dirname">g_path_get_dirname() </link>
|
|
Packit |
1470ea |
rather than
|
|
Packit |
1470ea |
<link href="https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-strrstr">g_strrstr() </link>
|
|
Packit |
1470ea |
and other manual searching functions.
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
</example>
|
|
Packit |
1470ea |
</section>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
<section id="path-validation-and-sandboxing">
|
|
Packit |
1470ea |
<title>Path Validation and Sandboxing</title>
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
If a filename or path comes from external input, such as a web page or
|
|
Packit |
1470ea |
user input, it should be validated to ensure that putting it into a file
|
|
Packit |
1470ea |
path will not produce an arbitrary path. For example if a filename is
|
|
Packit |
1470ea |
constructed from the constant string <file>~/</file> plus some user input,
|
|
Packit |
1470ea |
if the user inputs <file>../../etc/passwd</file>, they can (potentially)
|
|
Packit |
1470ea |
gain access to sensitive account information, depending on which user the
|
|
Packit |
1470ea |
program is running as, and what it does with data loaded from the
|
|
Packit |
1470ea |
constructed path.
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
This can be avoided by validating constructed paths before using them,
|
|
Packit |
1470ea |
using
|
|
Packit |
1470ea |
<link href="https://developer.gnome.org/gio/stable/GFile.html#g-file-resolve-relative-path">g_file_resolve_relative_path() </link>
|
|
Packit |
1470ea |
to convert any relative paths to absolute ones, and then validating that
|
|
Packit |
1470ea |
the path is beneath a given root sandboxing directory appropriate for the
|
|
Packit |
1470ea |
operation. For example, if code downloads a file, it could validate that
|
|
Packit |
1470ea |
all paths are beneath <file>~/Downloads</file>, using
|
|
Packit |
1470ea |
<link href="https://developer.gnome.org/gio/stable/GFile.html#g-file-has-parent">g_file_has_parent() </link>.
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
As a second line of defence, all projects which access the file system
|
|
Packit |
1470ea |
should consider providing a mandatory access control profile, using a
|
|
Packit |
1470ea |
system such as <link href="http://apparmor.net/">AppArmor</link> or
|
|
Packit |
1470ea |
<link href="http://selinuxproject.org/">SELinux</link>, which limits the
|
|
Packit |
1470ea |
directories and files they can read from and write to.
|
|
Packit |
1470ea |
|
|
Packit |
1470ea |
</section>
|
|
Packit |
1470ea |
</page>
|