backup operation: back up the files belong to www-run
Hello. I am making up regular backup procedure of a web server (sitting in the datacenter). There are a lot of files created by www-run (uploaded by users) needs to be backed up from my office. These file permission is 600. The backup script run in my office desktop, use ssh to fetch updated files and create backup in my office. ideas: 1. I can adjust umask so that the files created by apache has some user permission like 644 so that the back up script can use ssh to connect to the server as any user and being able to read these files; 2. I can adjust sshd permission to allow root remotely login to ssh (previous setting by our administrator is: root is not allowed for sshd, you must first login as a normal user and 'su', this is said to be more secure), and the backup script should run as 'root' on the web server, thus it can read these files belonging to www-run without necessarily have permission to do so; 3. tweak idea (2) a little bit, use 'sudo' rather then login as root to the web server. 4. I can adjust /etc/passwd to make the login shell of www-run to be /bin/bash (was: /bin/false) so that the backup script can ssh to the web server as www-run, this it can read any file apache server can read; Which method is more secure? How do you suggest me to do?
在 2006-10-28六的 16:54 +0800，张韡武写道：
Hello. I am making up regular backup procedure of a web server (sitting in the datacenter). There are a lot of files created by www-run (uploaded by users) needs to be backed up from my office. These file permission is 600. The backup script run in my office desktop, use ssh to fetch updated files and create backup in my office.
Better English: Hello. I need to decide how to back up my web server from my office. The webserver is in the datacenter far away. Among all files that needs to be backed up, a lot of them are owned by www-run and have permission of 600, these files are uploaded by the web visitors. My idea is I can run a script in crontab, on the desktop in my office, that connects to the web server through ssh and fetch files I need to back up. This script connects to the web server as a normal user, but then the script cannot read the files web visitors uploaded (permission denied). So far I thinked about 4 methods I can solve this problem, I want to share these ideas with experienced users on the group and listen to your suggestions;)
ideas: 1. I can adjust umask so that the files created by apache has some user permission like 644 so that the back up script can use ssh to connect to the server as any user and being able to read these files;
1: I try to set proper umask so that the files uploaded by visitors automatically have permission like 644. This way my backup script do have permission to read these files.
2. I can adjust sshd permission to allow root remotely login to ssh (previous setting by our administrator is: root is not allowed for sshd, you must first login as a normal user and 'su', this is said to be more secure), and the backup script should run as 'root' on the web server, thus it can read these files belonging to www-run without necessarily have permission to do so;
2: I try to let my backup script connect to the webserver as root. The webserver forbids root login, thus I may need to configure sshd to allow root login.
3. tweak idea (2) a little bit, use 'sudo' rather then login as root to the web server.
3: I try to use 'sudu', connect to the webserver as a normal user and 'sudo' to root to fetch the files.
4. I can adjust /etc/passwd to make the login shell of www-run to be /bin/bash (was: /bin/false) so that the backup script can ssh to the web server as www-run, this it can read any file apache server can read;
4: I try to let my backup script connect to webserver as user 'www-run'. To do so I need to give www-run user login permission, by changing its login shell from /bin/false to /bin/bash.
Which method is more secure? How do you suggest me to do?
so, which idea do you think is better? Any suggestions? -- 锐业软服（国内业务） http://www.realss.cn Real SoftService http://www.realss.com 销售咨询(Sales Department): 0086 592 20 99987 (Chinese, German, English) 国际业务(International Sales): 0086 10 8460 6011 (German and English) 联系：厦门大学科技园，嘉庚二号楼6楼 邮政：厦门大学2312号信箱（邮编361005）
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-10-28 at 19:50 +0800, ??? wrote:
My idea is I can run a script in crontab, on the desktop in my office, that connects to the web server through ssh and fetch files I need to back up. This script connects to the web server as a normal user, but then the script cannot read the files web visitors uploaded (permission denied). So far I thinked about 4 methods I can solve this problem, I want to share these ideas with experienced users on the group and listen to your suggestions;)
A fifth one: rsync, perhaps via ssh transport. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFQ0/VtTMYHG2NR9URAts3AJ9zkQXktmXYuT873BkCB+x1SaVs1gCdHdva n1zeLfo0QNxRmZVrgBeWNE0= =Um+q -----END PGP SIGNATURE-----
On Saturday 28 October 2006 14:40, Carlos E. R. wrote:
The Saturday 2006-10-28 at 19:50 +0800, ??? wrote:
My idea is I can run a script in crontab, on the desktop in my office, that connects to the web server through ssh and fetch files I need to back up. This script connects to the web server as a normal user, but then the script cannot read the files web visitors uploaded (permission denied). So far I thinked about 4 methods I can solve this problem, I want to share these ideas with experienced users on the group and listen to your suggestions;)
A fifth one: rsync, perhaps via ssh transport.
Yes, but IMHO this seems only a partial solution, as it does not take care of the read-permission problem. ;-) 600 means only wwwrun or root have read-access. But combined with root login via ssh-key would be not quite bad at all. Cheers, Leen
在 2006-10-28六的 17:33 +0200，Leendert Meyer写道：
Yes, but IMHO this seems only a partial solution, as it does not take care of the read-permission problem. ;-) 600 means only wwwrun or root have read-access.
But combined with root login via ssh-key would be not quite bad at all.
The webserver administrator is unfortunately no longer working here, so I got no ways to ask but in his original security policy, it is only possible to login via ssh-key (password login is disabled). Does it make sense to turn of root ssh login and to turn off password login at the same time? This is the current situation but I want to am I lowering down security level by enabling root login but keep password login disabled?
Cheers,
Leen
-- 锐业软服（国内业务） http://www.realss.cn Real SoftService http://www.realss.com 销售咨询(Sales Department): 0086 592 20 99987 (Chinese, German, English) 国际业务(International Sales): 0086 10 8460 6011 (German and English) 联系：厦门大学科技园，嘉庚二号楼6楼 邮政：厦门大学2312号信箱（邮编361005）
On Sunday 29 October 2006 00:50, 张韡武 wrote:
Does it make sense to turn of root ssh login and to turn off password login at the same time? This is the current situation but I want to am I lowering down security level by enabling root login but keep password login disabled?
Try not to get all uptight about ssh-key login as opposed to password. SSH login, whether it be by password or ssh-key (public key) is about as safe as is practical. Some people worry about password login mostly because of hysteria over key-stroke-timing (which can be easily overcome by humming a tune while you type passwords). Passwords need only be stored in you head. ssh-keys have to be written on a disk somewhere, which means the target machine is only as secure as the access machine, which in most cases means not at all. -- _____________________________________ John Andersen
在 2006-10-29日的 16:50 +0800，张韡武写道：
在 2006-10-28六的 17:33 +0200，Leendert Meyer写道：
Yes, but IMHO this seems only a partial solution, as it does not take care of the read-permission problem. ;-) 600 means only wwwrun or root have read-access.
But combined with root login via ssh-key would be not quite bad at all.
The webserver administrator is unfortunately no longer working here, so I got no ways to ask but in his original security policy, it is only possible to login via ssh-key (password login is disabled).
Next time I'll do it better: here is the better English version: The webserver administrator is unfortunately no longer working here, so I got no ways to ask him. In his original security policy, both password login and root login are disabled.
Does it make sense to turn of root ssh login and to turn off password login at the same time? This is the current situation but I want to am I lowering down security level by enabling root login but keep password login disabled?
Does it make sense to have both password login and root login disabled? I wonder if I enable root login (but keep password login disabled) am I lowering down security level significantly? If the backup script login as root and use ssh-key, this backup machine, once cracked down, give cracker full access to the web server. However I can do it this way that backup script ask for passphrase before connecting to remote web server. This require someone to go to that machine to type passphrase everyday when backup begins. How do you think? Is this the best approach?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-10-28 at 17:33 +0200, Leendert Meyer wrote:
A fifth one: rsync, perhaps via ssh transport.
Yes, but IMHO this seems only a partial solution, as it does not take care of the read-permission problem. ;-) 600 means only wwwrun or root have read-access.
Well, the rsync daemon runs as root: it would have access: An example that copies all the files in a remote module named "src": rsync -av host::src /dest Some modules on the remote daemon may require authentication. If so, you will receive a password prompt when you connect. You can avoid the password prompt by setting the environment variable RSYNC_PASSWORD to the password you want to use or using the --password-file option. This may be useful when scripting rsync. That's without ssh transport, but the manual explains how to add that. Like: rsync -av --rsh=ssh host::module /dest There are many combinations. I think that the remote user can be "www-run", but perhaps not if that requires a shell. I'm not sure about that. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRJiXtTMYHG2NR9URAijKAKCN1GsWcsmpNvLB7j2ye+cz7B8BQgCcDDBj SRTPQQpGcTymiDPrI3kvk9M= =XpO9 -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Saturday 2006-10-28 at 17:33 +0200, Leendert Meyer wrote:
A fifth one: rsync, perhaps via ssh transport.
Let me second Carlos' recommendation to use rsync and specifically to use an rsync DAEMON. That is the best answer to the problem that I'm aware of.
Yes, but IMHO this seems only a partial solution, as it does not take care of the read-permission problem. ;-) 600 means only wwwrun or root have read-access.
Well, the rsync daemon runs as root: it would have access:
You can run an rsync daemon as any user that has access to the files it needs to access (e.g. www-run). If you need to back up other files, you can run it as root and use the option to chroot the daemon for each transfer. In any case, rsync's configuration also stops the daemon accessing areas it shouldn't. Cheers, Dave
participants (5)
-
Carlos E. R. -
Dave Howorth -
John Andersen -
Leendert Meyer -
张韡武