Opened 8 years ago

Closed 7 years ago

#18131 closed defect (duplicate)

paranoid umask breaks the installed symlinks

Reported by: akimd (Akim Demaille) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: base Version: 1.8.0
Keywords: umask Cc: jochen@…, jmroot (Joshua Root)


Hi all,

It is the second time (second machine) that my texlive_base installation fails: I can't run pdflatex, but I can run pdflatex --version!!!

Since it was the second time, I decided to track down the issue.

It turns out that when launched to actually compile something, pdftex runs readlink(2), probably to decide what its behavior should be depending on its name. This is most probably *after* options such as --version are processed.

Here, our sysadm has installed paranoid rights: our umask is 066, and as a result the symbolic links created are not readable. This is not nice as it results in ls -l /opt/local/bin complaining that it can read the links. But it is not a real problem usually.

Here, since pdflatex (a symlink to pdftex) wants to readlink, it fails.

It is easy to reproduce harmlessly:

cd /tmp
sudo su
umask 066
ln -s /opt/local/bin/pdftex pdflatex
ls -l pdflatex
./pdflatex --version

It turns out that I found no way to chmod the symlink itself, so I had to recreate them all. Using zsh that's easy:

sudo su
umask 022
cd /opt/local/bin
for i in *(@)
  ln -sf $(readlink $i) $i

I suggest that texlive_base make sure the umask is correct.

As a matter of fact, I think port(1) should do it, instead of pushing this down to all the ports.


Change History (5)

comment:1 Changed 8 years ago by blb@…

  • Component changed from ports to base
  • Keywords umask added
  • Milestone changed from Port Bugs to MacPorts Future

The destroot phase does set a umask but from what you're saying it sounds like maybe the install and/or activate phases are not keeping those settings around?

Also, agreed that this is a base issue and not something which should just be fixed in one port.

comment:2 Changed 7 years ago by jochen@…

  • Cc jochen added
  • Version changed from 1.7.0 to 1.8.0

Apparently this issue still remains with MacPorts 1.8.0 -- are there any plans/ideas to fix it?

Actually, above zsh-code to manually fix the symlinks does not work for me... On the other hand, I've never used zsh and it might just be me, but it runs without error, just no link is changed...

comment:3 Changed 7 years ago by kuperman@…

It is also still broken in 1.8.1. I also had issues with applications installed into /Applications/MacPorts where my umask of 077 left everything unusable without a recursive chmod.

comment:4 Changed 7 years ago by jmroot (Joshua Root)

  • Cc jochen@… jmr@… added; jochen removed

Is this the same issue as #21389, and therefore fixed as well?

comment:5 Changed 7 years ago by jmroot (Joshua Root)

  • Milestone MacPorts Future deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Assuming dupe of #21389.

Note: See TracTickets for help on using tickets.