SSH Upload file permissions issue

Answered

When using the SSH Upload build step to move files from one Linux machine to another Linux machine, the destination files all have permissions that are different than the source files. Specifically they are all -rwxr-x--- at the destination.

Here is my setup:

I have a build configuration that is connected to a SVN repository with a script (.sh) and a config file (.config), among other things. I do some moving around of files and directories to prepare them for easy copying, and then I use SSH Upload to deploy to a test server. When I look at the checkoutDirectory, the files have the permissions I expect. But when I look at the test server they were deployed to, they all have the permissions -rwxr-x---.

My question is: Do I have to do something special with the SSH Upload step to preserve file permissions?

I also tried to create a separate Build Configuration with an Artifact Dependency, but ran into the same issue.

 

Thanks,

~Alex

0
11 comments

Hello Alex,

Could you please confirm source permissions? At a glance, TeamCity does not explicitly amend target permissions - but I have reached out to the development team in order to double-check that and will get back to you when update is available.

0
Avatar
Permanently deleted user

Original location (i.e. development SVN location) - Permissions are for User1

 

TeamCity Checkout directory - Permissions are slightly different, and are for User2, the User running TeamCity

 

SSH Upload copied location - Permissions are for "User2", but I assume that's actually based on how SSH is setup.

 

Additionally, my wonder was if the files in the checkout directory were given temporary permissions and are not changed until the end of the build configuration? I say this because while I was messing with how to copy files around, I noticed TeamCity has some other temp files in the directory while the build is running.

0

Alex,

Thank you for the details. I am going to try to reproduce this behavior now; could you please confirm the transport protocol in use for this build step? (e.g. SCP/SFTP)

0
Avatar
Permanently deleted user

We are using SCP.

0

Hello Alex,

The file permissions were indeed changed for me on test; I have been checking with 777 file, which got copied as 755. On further check, remote machine had (default) umask of 0022 which was applied because the file was newly-created. 

Could you please confirm the umask value for the user you use for the upload? Any chance that it is affecting the output?
I have also created a request to explicitly set the source file permissions after the transfer: https://youtrack.jetbrains.com/issue/TW-68409; please feel free to vote/comment as you see fit.

0
Avatar
Permanently deleted user

From what I can tell, the umask is 0002.

A newly created file for the same user that SSH Upload is using has -rw-rw-r--

0

Hello Alex,

Another factor in play could be that the user umask apparently could differ from SSH server one (see this StackOverflow article for details: https://serverfault.com/questions/228396/how-to-setup-sshs-umask-for-all-type-of-connections). Given the previously shared screenshots, I would believe the 0027 mask is in use for SCP connections (write is stripped from groups and all from others), but your latest one shows this is different for in-place file creation (read permission is preserved outside of SCP upload). 

Could you please try to upload a 777 file manually via SCP to the remote? I would expect it to be delivered as 750; if this is the case, you may want to reconfigure your SSH server (for instance, OpenSSH allows -u flag to define umask). If the file permissions are different (and/or preserved from source), please let me know. 

0
Avatar
Permanently deleted user

Here are the results of a 777 file on the original server scp'd to the remote server.

So it does appear that the remote server has 750 permissions.

However, I don't think that explains the extra permissions the TeamCity files are getting. From a few posts back, you can see that an original file of -rw-rw-r-- permissions has -rwxr-x--- permission on the remote server. i.e. User and Group execute was added, and Group write was taken away. (as well as anyone read). Unless what you're saying is that while the build is running files in the TeamCity Checkout Directory have 777 permissions.

0

Hello Alex,

Indeed - sorry, somehow I have missed the added execution permission which, of course, could not be explained by the umask hypothesis. As I have mentioned, TeamCity does not explicitly set permissions yet, but from the ls -l output it appears almost like all target files got the same permission set which is curious.

I will check if there are any other environment settings which could affect the behavior (e.g. by adding execution permissions) and get back to you should I find something. A fix for aforementioned issue (explicitly set permissions after transfer) should also help here; as a workaround until this fix is delivered, I would suggest to consider a custom command-line step executing 

scp -p

to preserve source file permissions.

Apologies for the inconvenience this might have caused.

0
Avatar
Permanently deleted user

"Indeed - sorry, somehow I have missed the added execution permission which, of course, could not be explained by the umask hypothesis."

I think this theory could still be correct, if we assume that the files in the Checkout Directory were 777 at the time of SSH transfer. The test 777 file you had me transfer came through as the same permissions we see in this issue. (Compare my first response with my fourth response) I don't know why the Checkout Directory files would be 777, but that explanation at least makes logical sense.

This has not caused us too many issues, as we are newly using TeamCity and are currently deploying a small number of files to our Test system. i.e. we can manually change the permissions after the deploy or at least prior to manually pushing to Production. So it's working "well enough" for now, but I will keep in mind the workaround for future larger projects.

As always with this forum, thank you for the speedy responses.

0

Hello Alex,

I agree, we could see the similar result if source file was 777, and I will ask the development team to double-check if there are any edge cases which could lead to this. 
I see, thank you for the update on the scope of this issue! Your help with the issue description and details is really appreciated.

I am still checking through other explanations and will get back to you if I find something. 

0

Please sign in to leave a comment.