Opened 15 years ago

Closed 14 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)
Port:

Description

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
exit
ls -l pdflatex
./pdflatex --version
./pdflatex

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 *(@)
do
  ln -sf $(readlink $i) $i
done

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.

Cheers.

Change History (5)

comment:1 Changed 15 years ago by blb@…

Component: portsbase
Keywords: umask added
Milestone: Port BugsMacPorts 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 15 years ago by jochen@…

Cc: jochen added
Version: 1.7.01.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 15 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 14 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 14 years ago by jmroot (Joshua Root)

Milestone: MacPorts Future
Resolution: duplicate
Status: newclosed

Assuming dupe of #21389.

Note: See TracTickets for help on using tickets.