Symlinks: a render writes through a link, a check-then-use race, and a bad link blocking checkout

Abierto
  • ¿Algo no está bien?
#283 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
git, rust
Área
devtools, security

Línea de trabajo

Start with crates/newgit-core/src/manager.rs around line 3109 and read the render write path, then compare it with the symlink refusal in capture and the behavior of tracker checkout/pull. The issue identifies four open safety and behavior decisions, including an O_NOFOLLOW approach for tracked-file reads. Done means resolving these cases and defining the expected behavior for checkout and symlinked directories.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

#281 (for #258) stops capture from following symlinks. Left open, most important first:

  • A render writes through a symlink. If a [[render]] path is a link, rendering writes into the link's target, which can be outside the workspace (crates/newgit-core/src/manager.rs, around the render write, ~line 3109). This is the write side of #258: anything that can put a link at a rendered path can make newgit rewrite an arbitrary file the user can write, with ports and exports substituted in. The render should refuse a link at its path, as capture now does, naming the path and target.
  • A check-then-use race remains. A regular file swapped for a link between the check and git hash-object would still be followed. Closing it means reading tracked files in-process with O_NOFOLLOW instead of handing paths to git.
  • A bad link now blocks tracker checkout/pull. The safety capture before them refuses a link that leaves the workspace, so they fail until the link is removed by hand. The error says so. Should checkout be able to replace the link itself (the issue noted it used to), given the user asked for the lane's content?
  • A tracked path under a symlinked directory is always refused, even when the directory points inside the workspace, matching git's "beyond a symbolic link". Stricter than strictly needed; relax for the inside case?
Lenguaje dominante
Rust
Estrellas
0
Forks
0
Merge medio
7 h 15 min
PR fusionados (30 d)
87

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Spheroman/newgit

Todos los issues de Spheroman/newgit

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.