When SCP'ing to my Fedora server, a user keeps getting errors about not being able to modify file timestamps ("set time: operation not permitted"). The user is not the owner of the file, but we cannot chown
files to this user for security reasons. The user can sudo
, but since this is happening via an SCP/FTP client, there's no way to do that either. And finally, we don't want to have to give this user root access, just to allow him to use a synchronization like rsync or WinSCP that needs to set timestamps.
The user is part of a group with full rw
permissions on all relevant files and dirs. Any thoughts on how to grant user permission to touch -t
these specific files without chown
ing them to him?
Further Info This all has to do with enabling PHP development in a single-developer scenario (ie: without SCM). I'm trying to work with Eclipse or NetBeans to work on a local copy of the PHP-based (WordPress) site, while allowing the user to "instantly" preview his changes on the development server. The user will be working remotely. So far, all attempts at automatic synchronization have failed – even using WinSCP in "watch folder" mode, where it monitors a local folder and attempts to upload any changes up to the remote directory error out because it always tries to set the date/timestamp.
The user does have sudo access, but I have been told that it's really not a good idea to work under 'root', so I have been unwilling to just log in as root to do this work. Besides, it ought not to be necessary. I would want some other, non-superuser to be able to do the same thing – using their account information, establish an FTP connection and be able to work remotely via sync. So the solution needs to work for someone without root access.
What staggers me is how much difficulty I'm having. All these softwares (NetBeans, Eclipse, WinSCP) are designed to allow synchronization, and they all try to write the timestamp. So it must be possible. WinSCP has the option to turn off "set timestamp", but this option becomes unavailable (always "on") when you select monitor/synchronize folder. So it's got to be something that is fairly standard.
Given that I'm a complete idiot when it comes to Linux, and I'm the dev "server admin" I can only assume it's something idiotic that I'm doing or that I have (mis)configured.
Summary In a nutshell, I want any users that have group r/w access to a directory, to be able to change the timestamp on files in that directory via SCP.
Best Answer
Why it doesn't work
When you attempt to change the modification time of a file with
touch
, or more generally with the underlying system callutime
, there are two cases.Why this typically doesn't matter
--omit-dir-times
(-O
).Solutions
Ok, stop right there. Just because there's a single developer doesn't mean you shouldn't use SCM. You should be using SCM. Have the developer check in a file, and give him a way to press a “deploy” button to check out the files from SCM into the live directory.
There is absolutely no technical reason why you shouldn't be using SCM, but there may be a human reason. If the person working on these files styles himself “developer”, he should be using SCM. But if this is a non-technical person pushing documents in, SCM might be too complicated. So go on pushing the files over FTP or SSH. There are three ways this can work.
rsync
has an option to not synchronize times. Scp doesn't unless you tell it to. I don't know WinSCP but it probably can too.apache
user, then the usual approach would be to allow the user SSH access asapache
. The easy approach is to have the user create an SSH private key and add the corresponding public key to~apache/.ssh/authorized_keys
. This means the user will be able to run arbitrary commands as theapache
user. Since you're ok with giving the user sudo rights anyway, it doesn't matter in your case. It's possible, but not so easy, to put more restrictions (you need a separate user database entry with a different name, the same user ID, a restricted shell and a chroot jail; details in a separate question, though this may already be covered on this site or on Server Fault).¹ Or, for an empty file, write a byte and then truncate.
² Barring additional complications, but none that I know of applies here.