Updating a port. Need to make the install directory writable

Lord Bung

Lord Bung

I'm trying to update a port with no maintainer, games/pcgen. To run properly as a normal user, the install directory needs to be writable. The app writes a config file, a lock file, a number of log files, and possibly other files to its install directory. The port does not have a separate pkg-plist file. If it did, I think I would have already succeeded at this since there are innumerable examples of changing the mode in the pkg-plist file in other ports. There are only a few examples of changing the mode when a PLIST_FILES variable is used, and I have not been able to get this to work following those examples. I've tried a few different approaches to this.

Here is the original code from the Makefile.

Code: 
PLIST_FILES=    bin/pcgen
PORTDATA=    *
PORTDOCS=    *
PLIST_DIRS=    %%DATADIR%%/characters

I have tried
Code: 
PLIST_FILES=    bin/pcgen "@dir(,,0777) ${DATADIR}"

Code: 
PLIST_DIRS=    %%DATADIR%%/characters  @dir(,,0777) %%DATADIR%%
and
Code: 
post-install:
    ## Make installation directory writable
    #${CHMOD} 0777 ${DATADIR}
    ${CHMOD} 0777 ${PREFIX}${DATADIR}

portlint issues a warning for that last one. In addition to what's listed above, I've tried using single, double, and no quotes around some of these without any apparent effect. In any case, with each of these attempts, the install directory, /usr/local/share/java/pcgen, is never made writable when pcgen is installed.

If I do succeed at getting the mode set in PLIST_FILES, will make deinstall remove the directory even if config files, etc. are left behind? That would be an unwelcome change.
 
If different users run that, could they overwrite config files generated for a different user?
It seems to me that a user running that should probably generate their own config file, I think current conventions would be $HOME/.config/pcgen.
 
Here are the contents of the config.ini pcgen writes to the install directory when first run.

Code: 
#Wed Mar 08 19:28:47 EST 2023
systemsPath=@system
country=US
pluginsPath=@plugins
themesPath=@lib/lnf/themes
previewPath=@preview
language=en
osPath=@outputsheets
docsPath=@docs
lookAndFeel=Nimbus
showSplash=true
pccFilesPath=@data
settingsPath=/home/jon/.config/pcgen

Where to put the configuration files is one of the things pcgen asks when it's run the first time, which, as you can see above, is hard coded to /home/jon/.config/pcgen on my machine. pcgen does give several options as to where to put the configuration files. I'm not sure how much thought was given to having multiple users by the writers of pcgen. Having settingsPath use a variable like $HOME would be preferable. I may decide to contribute to the project, but as far as updating the port, changing what pcgen writes to the config.ini in its install directory is out of scope. :( Other settings changes are, in fact, stored in /home/jon/.config/pcgen. I'd just like to update the port so that less knowledgeable users, which included myself a week ago, will not get a series of errors because the install directory is not writable.

Also, without the config.ini in the install directory, pcgen goes through it's initial setup with every run, and running that every time is not a good user experience. :(

EDIT: or is it out of scope? Now, I'm thinking about it...
 
Ok, I did some testing and the default option for setting the configuration directory in pcgen is "Freedesktop configuration sub-directory", which, I believe, is in the user's home directory. So, if I'm correct, by default it will work correctly for multiple users. The config.ini in the install directory has
Code: 
settingsPath=FD_USER
when the defaults are accepted.

In any case, this port will be much improved if I can make the install directory writable.
 
SirDice said:
Please, for the love of everything that's holy, don't set 777 permissions.
Click to expand...

😂 What? Why not? I suppose it does not need to be group writable... 😜

I didn't write the software. I'm just trying to get the port to work better. pcgen does write files to its install directory. Specifically, it creates new files when it is run and likely makes changes to existing files as well. The current port simply downloads the already compiled Java app in the form of a zip file and extracts it to its install directory. I am not eager to create a patch of some sort to cause it to write persistent files to some other directory along with causing the port to compile this from source.

Another alternative would be to install it in a non-standard location, /opt or some such, that is user writable by default.

I'm open to suggestions. ;) And I'd also like to understand your concerns.
 
I don't install from source often In FreeBSD but If I was to and it needed to be updated to work. I just get get source and put it in my own home dir and fix it, either way, then run (configure) make, sudo make install then it works e16 epplets being one such piece of SW I modify to get it to do what I want it to.. In Linux I usually use Slackbuilds sometimes as I run Slackware (linux) to keep the system in the know about it being installed.
 
Prior to digging into this, I did not understand why pcgen did not work properly on Freebsd, whether installed via the port or downloaded manually. So, I reluctantly ran it on a different computer. Not my preferred solution. For me at least, I see value in having a port of this software that works without issues - however that is resolved.

I have started, but have not yet completed, reading the Porter's handbook. So far, I have not read any best practices information, there or anywhere else, about not having the install directory be user writable. I would like to understand the concerns you have about this SirDice and zirias@. If you have the time, I'd welcome an explanation. If there's any documentation on this that someone could point me to, I'd also be much obliged.
 
Lord Bung said:
Prior to digging into this, I did not understand why pcgen did not work properly on Freebsd, whether installed via the port or downloaded manually. So, I reluctantly ran it on a different computer. Not my preferred solution. For me at least, I see value in having a port of this software that works without issues - however that is resolved.

I have started, but have not yet completed, reading the Porter's handbook. So far, I have not read any best practices information, there or anywhere else, about not having the install directory be user writable. I would like to understand the concerns you have about this SirDice and zirias@. If you have the time, I'd welcome an explanation. If there's any documentation on this that someone could point me to, I'd also be much obliged.
Click to expand...
off the top of my head without reading someone else reasoning behind it. as this OS and Linux you can build your own SW and run it in your home directory for your own personal use. therefore the need to have it build and run without putting root ownership on every file thereby now having to be root to do anything with it for one reason as I am sure there is another.

otherwise you only need to be root or have root permissions to do this which is easily fixed if it is only your system just log in the cli as su to get root, or use sudo before every command.

in slackware Linux using a slackbuild script it uses root permissions to do everything in /tmp to create its install tar ball. then sudo with the install command is used to install it into the system. Therefore root is being used for the entire process. Because by design root (admin) is the only one that can install software on the system side.

the ~/bin is used for that user only software
 
Lord Bung said:
[...] having the install directory be user writable. I would like to understand the concerns [...]
Click to expand...
  • It's a gaping security hole. Any user can tamper with "installed" programs.
  • It potentially breaks package management (the package database doesn't exactly know about all "installed" files).
 
You must log in or register to reply here.
Back
Top