configure /tmp/.zef directory for root / none root users

melezhik commented 1 month ago

Context

sudo zef install SomeModule --force
# note - now without sudo
zef install SomeModule --force

Expected Behavior

both command should succeed

Actual Behavior

the second command fails with error

[task run: task.bash - bash: zef install Term::TablePrint]
[task stdout]
17:19:17 :: ===> Searching for: Term::TablePrint
[task stderr]
17:19:20 :: failed to create directory: /tmp/.zef/1720707556.113470/1720707560.113470.5062.5381259584265
17:19:20 :: task exit status: 1

The reason is zef is trying do to something with files located at /tmp/.zef/ directory which was created with root user during first run:

$ stat /tmp/.zef/
  File: /tmp/.zef/
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 8,17    Inode: 280422      Links: 3
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-07-11 17:20:37.803299584 +0300
Modify: 2024-07-11 17:18:48.158533802 +0300
Change: 2024-07-11 17:18:48.158533802 +0300
 Birth: 2024-07-11 17:18:48.158533802 +0300

Your Environment

$ eval $(/opt/sparrowdo/rakudo/rakudo-moar-2024.06-01-linux-x86_64-gcc/scripts/set-env.sh --quiet)

$ raku -v
Welcome to Rakudo™ v2024.06.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2024.06.

Debian12

ugexe commented 1 month ago

fwiw you can work around this by setting ZEF_CONFIG_TEMPDIR or changing the appropriate field in the config file

melezhik commented 1 month ago

Yeah, thanks for that hint, how about implementing this separation on zef side, so an end user don’t bother about that ?

On Thu, Jul 11, 2024 at 5:53 PM Nick Logan @.***> wrote:

fwiw you can work around this by setting ZEF_CONFIG_TEMPDIR or changing the appropriate field in the config file

— Reply to this email directly, view it on GitHub https://github.com/ugexe/zef/issues/563#issuecomment-2223149654, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHRHSMWI2ZAJFR3AG4YFVLZL2MAJAVCNFSM6AAAAABKXDMEK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRTGE2DSNRVGQ . You are receiving this because you authored the thread.Message ID: @.***>

ugexe commented 1 month ago

Potentially. But it is just using $*TMPDIR from core raku. I wonder if raku should consider writable permissions when it picks the value for that dynamic variable

niner commented 1 month ago

The problem is not $*TMPDIR itself but using a fixed subdirectory of that. That's bad practice also from a security standpoint. Predictable temp file names can be exploited via symlinks.

I suggest using something like `$*TMPDIR ~ flat('a'..'z', 'A'..'Z', 0..9, '_').roll(8).join ~ '.zef' instead

melezhik commented 1 month ago

The problem is not $*TMPDIR itself but using a fixed subdirectory of that. That's bad practice also from a security standpoint. Predictable temp file names can be exploited via symlinks.

I suggest using something like `$*TMPDIR ~ flat('a'..'z', 'A'..'Z', 0..9, '_').roll(8).join ~ '.zef' instead

Still does not guarantee collisions?

niner commented 1 month ago

There would be a 1 in 248,155,780,267,521 chance of a collision. In other words it just won't happen. But if you are afraid, just make that prefix longer.

ugexe commented 1 month ago

For now I'll be changing the TempDir configuration entry from $*TMPDIR/.zef/{time}.{$*PID} to $*TMPDIR/.zef.{time}.{$*PID}. That is still a somewhat predictable-ish path, but I think it is a good enough solution for the time being.

ugexe / zef