Access denied: /tmp/blahblahblah

[ratijas]

After recent upgrade, I started getting strange messages from various tools, most verbose ones being like this:

Access denied: /tmp/gitstatus.POWERLEVEL9K.1000.199522.1603996112.1.lock

/home/ratijas/.zgen/init.zsh:35: can't create temp file for here document: Access denied
/home/ratijas/.zgen/init.zsh:35: can't create temp file for here document: Access denied
-- zgen: Files in $ZGEN_RESET_ON_CHANGE changed; resetting `init.zsh`...
-- zgen: Deleting `/home/ratijas/.zgen/init.zsh` ...
Creating a zgen save
-- zgen: Creating `/home/ratijas/.zgen/init.zsh` ...
-- zgen: Initializing completions ...
mktemp: cannot create file with template «/tmp/virtualenvwrapper-initialize-hook-XXXXXXXXXX»: Access denied
touch: unable to execute touch '': No such file or directory
ERROR: virtualenvwrapper could not create a temporary file name.

So, basically they all have something to do with access to files on /tmp.

I wonder, could this be related to #651?

---

My permissions on /tmp are drwxr-xr-x, and I'm pretty sure they were drwxrwxrwx just recently.

% ls -ld /tmp
drwxr-xr-x 20 root root 620 Oct 29 18:08 /tmp

[ratijas]

https://unix.stackexchange.com/questions/71622/what-are-correct-permissions-for-tmp-i-unintentionally-set-it-all-public-recu

What are correct permissions for /tmp ?

The normal settings for /tmp are 1777, which ls shows as drwxrwxrwt. That is: wide open, except that only the owner of a file can remove it (that's what this extra t bit means for a directory).

[fosskers]

Yes I think this is related to that fix. Let me look into this.

[ratijas]

Your /tmp might be full, can you check what's in there?

It was going to be a big post about my beautiful Btrfs layout and snapper which manages backups to keep free space above the threshold quota, but then I realized my /tmp is just an old plain tmpfs.

Anyway, nothing unusual going on there. Low usage values, a lot of free RAM, and untouched swap.

% df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           7.8G   30M  7.8G   1% /tmp

I'm pretty sure the problem arouse because of the permissions that were f###ed up.

[fosskers]

This warrants a patch release, methinks.

[fosskers]

Here is the offending line:

    -- This is a migration strategy - it ensures that directories created with
    -- old versions of Aura automatically have their permissions fixed.
    then void . runProcess . setStderr closed . setStdout closed $ proc "chmod" ["755", pth]

[fosskers]

Proposed fix:

    then case pth of
      "/var/cache/aura/vcs" -> void . runProcess . setStderr closed . setStdout closed $ proc "chmod" ["755", pth]
      "/tmp" -> void . runProcess . setStderr closed . setStdout closed $ proc "chmod" ["1777", pth]
      _ -> pure ()

[fosskers]

Seems to leave the permissions as they were:

colin@yumi /tmp> la
Permissions Size User  Date Modified Name
drwxrwxrwt     - root  29 Oct 14:50  .

The changes introduced above can be removed in a future release.

[ratijas]

Proposed fix:

...more like:

    then case pth of
      "/var/cache/aura/vcs" -> setMode "755"
      "/tmp" -> setMode "1777"
      _ -> pure ()
      where
        setMode mode = void . runProcess . setStderr closed . setStdout closed $ proc "chmod" [mode, pth]

or whatever is the right syntax / indentation in Haskell.

[ratijas]

i LOVE the fact that mere upgrade of aura-bin f###ed up permission again, so I had to run one more time with warning: aura-bin-3.2.2-1 is up to date -- reinstalling to actually fix it back. xDxDxD

[ratijas]

That sounds like a job for a pacman's post-install script, actually.

[fosskers]

Thanks for your patience in all this. Aura 4.0 will definitely handle things a little better, and provide a migration command (or a post-install script).

[ratijas]

No worries :)
At the end of the day, we got it all patched up, thanks to you and your fast pace of development. Hopefully, not too many users had time to upgrade to 3.2.0/3.2.1.

[fosskers]

Repo: fosskers/aura	Count: 28	Date: 2020-10-29	Asset: aura-3.2.2-x86_64.tar.gz
Repo: fosskers/aura	Count: 240	Date: 2020-10-27	Asset: aura-3.2.1-x86_64.tar.gz

So most users haven't moved yet, and will never notice the issue.

[VannTen]

I stumbled upon this too (thx for the fix 👍 ). Quick question, should'nt the build (and so the creation / permission modification of directories) be performed as the building user, to avoid that kind of problems ?
(I'm not familiar with aura architecture)

[fosskers]

The build is indeed performed as the user in the end, but you're right that it's probably a better idea to give the top level build directory (be it /tmp or /var/cache/aura/vcs for git packages) open permissions, and then having the cloning be performed after su-ing down into the build user's account.