When using the SFTP plugin to publish to an existing site (replacing a page that was already there before we started using Rhythmyx), I get the following error message:
file permissions mismatch. Expected 744 got 664
Do web pages really need to be executable?
FYI: Though the publication log indicates an error, the pages do publish anyway. I hate to have to constantly tell myself, “That’s not a real error.”
Are you sure that this is happening on a File and not a Directory?
Yes, I get the same message for both existing files, but not for the new file:
12:10:52 345ms DEBUG testing file permissions /srv/www/vhosts/itunes/initiative.html -rw-rw-r-- publisherId="302" publicationId="361" siteId="322" editionId="321" clistId="312" ctypeId="499" contentId="325" action="publish" com.percussion.consulting.publisher.client.PSOSFtpClient http-0.0.0.0-9992-8
12:10:52 345ms WARN file permissions mismatch. Expected 744 got 664 publisherId="302" publicationId="361" siteId="322" editionId="321" clistId="312" ctypeId="499" contentId="325" action="publish" com.percussion.consulting.publisher.client.PSOSFtpClient http-0.0.0.0-9992-8
12:10:52 346ms ERROR Permission denied publisherId="302" publicationId="361" siteId="322" editionId="321" clistId="312" ctypeId="499" contentId="325" action="publish" com.percussion.consulting.publisher.client.PSOSFtpClient http-0.0.0.0-9992-8
When I looked on the web server, I saw that the two existing files had new timestamps, the same as the new file.
Maybe Web pages don’t need to be executable, but they need to be in a directory that’s executable.
As a result of the problem I’m having, when I publish new folders (create them fresh on the web server), their permissions don’t allow me to view their contents from a browser. The browser gives me a 403 error: “You don’t have permission to access /itunes/news/ on this server.” If I republish to an existing folder that already has the correct permission, I don’t have any problem. The same thing happens when publishing to various directories on my web server.
SFTP publishing always creates files and folders with permission 744. But when I use my usual SFTP client, WinSCP, to upload files and create directories, I get permission 644 for files and 2775 for directories (775 or 755 would also work) . Either way, Rhythmyx and my SFTP client are both using my own SFTP username, but resulting in different permissions.
Hi Michael
I’ve had a similar problem with the sFTP plugin in that Rhythmyx wouldn’t publish the homepage if it didn’t already exist. Detailed this to Support and a new sFTP plugin has now been created.
Havent had chance to make the changes but worth contacting support about it.
Cheers
James
The issue here appears to be the way that we handle the umask. The default umask is 033 which results in permissions of 744.
We don’t process files and directories differently: we just have one set of target permissions. (I didn’t change this when I built the new plug-in, I just switched from the old version of j2ssh to the most recent version of JSch).
I suppose we could improve this in 2 ways: by suppressing the permissions check if the user does not actually set a umask, and by adding “owner execute” to the permissions when creating a directory.
If this is a real problem for you (as opposed to a minor annoyance), please let me know (and report it to support so that it can be tracked) and I’ll see if the code can be changed to separate these functions.
Dave
I’m talking with our server admin folks, but yes, it’s a major problem, since web pages published into new directories currently can’t be browsed.
My .bashrc file says “umask 002” and typing “umask” on the web server gets me “0002”. The Linux user that installed Rhythmyx gets “0022”. So umask seems to be set.
Just to be clear… what you need is for us NOT to change the permissions on files after they are published, and let the “umask” of the user set them instead.
Can you confirm (with your admins) that this will work on your servers?
If this is what you want, I can build a version of the SFTP plugin that will not check the permissions unless an explicit UMASK parameter is passed in the publisher config.
The “implicit” umask of the login user (the one you specify in the FTP user name/password fields) will govern in these cases.
Dave
After talking with our admin, probably allowing the user’s umask to set the permissions would be the best way to go. Then Percussion can explicitly state in the documentation what users should set it to. That method also allows more customization in what you want the permissions to be. Could you set a safe default permission (755?) if the umask cannot be found, so we don’t break things if umask cannot be set because of server rules/configurations? How does umask work on Windows machines? Does the concept of permissions even carry through?
For your reference, TAR: MA-08-10-0064 has been opened on this issue.
Michael,
I’m a bit confused by this last one. It’s not clear to me when you are talking about the “umask of the login user” and when you are talking about the “umask set by the SFTP plugin”.
Here’s what we are proposing to implement:
If the user specifies a UMASK parameter in the publisher configuration, we will set that umask on the remote session inside the SFTP plugin, and the create the files as we do today. After the files are created we will check that the permissions match the expected values, and attempt to reset them if they do not match.
If the user DOES NOT specify a UMASK parameter in the publisher configuration, we will not do anything with file permissions, we will just login as the remote user and create the files/directories as needed. The umask which is set in the remote users login scripts (e.g. .profile) will control the file permisssions, and Rhythmyx will NOT check the permissions after the files are created.
We will recommend in the documentation that user do NOT use the umask parameter unless there are circumstances that prevent them from controlling the umask via the login scripts of the remote user.
File permissions have NO effect on Windows servers. You either get an error or xyzzy - “nothing happens”. In either case we ignore this case today: all errors that occur when setting the umask or the permissions are logged and ignored.
Please confirm that the proposed solution will work for you.
Dave
Yes, that solution will work for us. We weren’t thinking about the umask set by the SFTP plugin, just the umask of the login user in Linux. We talked about breaking things if we couldn’t set a umask on the web server, but it sounds like the ability to set it in the publisher configuration would get around that problem if it ever arose.
We do have a couple of customers who don’t have control over the default file permissions (I don’t know why) and for these customers we must provide the override of setting the umask in the plugin.
I think the best approach is to control the umask in the login script, as we’ve been discussing. I think the changes are pretty easy to implement, but the testing might be a bit hard: there are a number of different combinations to test.
Dave
Adding umask 002 and umask 113 as configuration parameters in the Publisher does make the pages and directories visible in my browser. With TAR#: MA-08-10-0077, we discovered that the new version of the SFTP plugin is publishing new files only to my home directory on the web server (home/mdmcginn/srv/www/vhosts/ instead of /srv/www/vhosts/), not to the publishing root location. The old version was publishing both to the Rhythmyx user’s home directory on the Rhythmyx server as well as the expected Publishing Root Location.
According to the logs, the publishing path doesn’t include the opening / , so if you can just add the opening /, all should be well. My publishing configuration includes the slash, so maybe the plugin appends $HOME to my publishing root. Certainly $HOME/$YOUR_PATH is right where it put the files.
I tried to change my site registration to something like “…/…/…/srv/www/vhosts/itunes” but I haven’t been successful that way. However, a symlink works: putting an “itunes” symlink in the root of my home directory linked to the correct location on the Web server, and changing the Rhythmyx publishing definition to “/itunes” instead of “/srv/www/vhosts/itunes”. That publishes to the correct location using the new version of the plugin.
Michael,
Just so I understand, the issue is that “absolute” paths don’t work properly. If we see a path with a leading “/” we should interpret that as the root directory of the machine rather than the home directory of the user (which is what I think happens now).
I’ll have to look at the SFTP library code: I’m not sure if this is supported or not (it seems like a potential security problem to me).
I know that we explicitly disallow paths with /…/ in them, so I would not expect that to work. To allow for building missing directories, we have to “walk” thru the file path, and disallowing . and … makes that code simpler.
BTW, the “new version” that we are testing IS the code that will ship with 6.6. I’d like to know if it’s working properly before the release rather than after it.
Dave
Dave
If we see a path with a leading “/” we should interpret that as the root directory of the machine rather than the home directory of the user (which is what I think happens now).
Yes, that’s what we would prefer. Thank you.
The only big problem I see is that all previous versions of the SFTP plugin (and the FTP plugin, for that matter) interpreted “/” as the home directory of the login user. We may have to provide some backwards compatibility so that we don’t break other customers.
I’ll let you know what we decide to do. I don’t think this is a big change, but there’s a lot of the plate right now.
Dave
I just realized that simply creating a symlink to “/www” or “/srv” from my home directory on my web server will allow me to use the same publishing paths that I’ve been using. That would work for other customers who serve web pages from a single directory that isn’t /home/username/public_html, such as /var/www or /var/www/htdocs.
After some internal discussion, we’ve decided not to fix this at this time.
Because the SFTP and FTP plugins have always worked this way, we’d need to add a flag (e.g. “AllowAbsolutePaths”) to the configuration of the publisher plugin. At this point, we’re past code freeze for Rhythmyx 6.6, and the QA team is very reluctant to accept any more functional changes.
I also don’t want to add something to the PSO version of this code that I know will not be added to the product (it’s one more potential issue on upgrade).
Since there’s an easy workaround, we’re going to do nothing for now. If there’s a lot of demand for this feature, or somebody comes up with a use case that requires this functionality, we will reconsider.
Dave