Difference between pages "FLOP:Automatic FS Snapshots" and "SFTP Only Access"

From Funtoo
(Difference between pages)
Jump to: navigation, search
m
 
 
Line 1: Line 1:
= Goal and context =
+
= Context =
  
Modern filesystem like BTRFS and ZFS supports a feature known as snapshot (some of them like NILFS2 uses that capability in a even more aggressive manner). Basically, a snapshot is nothing more than coherent "photograph" of a filesystem structures and data blocks pointed by them thus enabling the system administrator to see a filesystem in its *exact* state at the time the snapshot was taken even if some files have been deleted/changed/created since the snapshot creation.
+
In some cases, it can be useful to set up an access on your Funtoo box such as a user:
 +
* does not see the whole contents of the machine but, instead, remains "jailed" in a home directory
 +
* is able to transfer files back and forth on the box via SFTP
 +
* does not have access to a shell
  
Filesystems snapshotting is not a new feature as it is known for quite a long time in the Linux world especially by LVM users. However, one of the areas where filesystems like BTRFS shines is it uses a technique known as Copy-on-Write: while a LVM snapshot physically replicates the stripes (LVM is disconnected from the filesystems lying in the LVM logical volumes and can make no assumptions), CoW filesystems like BTRFS are clever enough to avoid unnecessary data blocks duplication. Thus, at the exact time a snapshot is taken there is no difference between a filesystem and its snapshot meaning the snapshot size is very small. As the time goes on and data blocks are modified, the filesystem will detect alterations attempt and will duplicate all the necessary data blocks to preserve the original ones. On the other side, old and obsolete snapshots must be  deleted from time to time to free up the data blocks that have been "locked in the past".
+
Such a SFTP only access is easy to setup:
  
Present proposal pretends to be the "big picture" of integrating snapshotting capabilities of modern CoW filesystems like BTRFS/ZFS in portage. Such an integration will enable sysamdins to easily recover from a disaster coming from a clunky update (or worse, a silent and catastrophic libpng-like update). For the project credibility, it mitigiates the degree of an major issue coming out of the blue. For Funtoo developers, the gain is they do not have to replicate their live filesystem in a chroot or play with virtual machines or jailed tests environments of any kind. In the case of something go wrong, it is simple to do a filesystem rollback just as if nothing has ever happened.
+
# Assign a group (e.g. ''sftponly'') to users that must be restricted to a SFTP-only account
 +
# Change a bit the configuration of OpenSSH so that users belonging to your sftp-only group are given a chrooted access
 +
# Make OpenSSH ignore any other command than running sftp-server on the server side for users belonging to your sftp-only group (this is where the trick lies !)
  
= First idea =  
+
= Quick start =
  
Quick functional description: the sysadmin want to install/update/delete/clean up dependencies and use the appropriate command (emerge/emerge -u/emerge -C/emerge --depclean...):
+
First, a dedicated group must be created. For the sake of the example we use sftponly here, use whatever name fits your preferences:
* The command starts by doing a snapshot of system directories and then installs or remove all of the specified packages/dependencies (transactional operation).  
+
* If something goes wrong and the user resume the process (emerge --skip-first / emerge --resume) no snapshot is taken and the process goes on as it actually does
+
* If the  something goes wrong and the user then chooses to manually emerge some packages by hand instead of doing, let's say, emerge -uaDN @world, another snapshot is taken.
+
  
This guarantee that an "image" of the filesystem is kept before each transaction (installation/removal of several packages in a single portage command). When the sysadmin is happy, he removes the now unneeded snapshots by its own.
+
<pre>
 +
# groupadd sftponly
 +
</pre>
  
= Behavior control =
+
Next in the configuration of OpenSSH (located in '''/etc/sshd/sshd_config''') locate:
  
As the Funtoo philosophy wants, the snapshotting capabilities integration in portage is always optional and the behaviour is governed via FEATURES (e.g. FEATURES=".... fs-snapshots"). As we can't predict what the future is made of, it is necessary to have a flexible control on the how the filesystem manipulation tools used to produce snapshots. This can be done with environment variables like:
+
<pre>
 +
Subsystem      sftp    /usr/lib64/misc/sftp-server
 +
</pre>
  
BTRFS_PORTAGE_SNAPSHOT_CMD="btrfs subvolume snapshot "
+
and change it for:
ZFS_PORTAGE_SNAPSHOT_CMD="zfs snapshot "
+
 
+
By default, portage will use a YYYYMMDDTHHMMSS for the snapshot name thus doing something like:
+
 
+
* btrfs subvolume snapshot /mountpoint /root/mountpoint-YYYYMMDDTHHMMSS  (in the case of / only the YYYYMMDDTHHMMSS portion is kept)
+
* zfs snapshot pool/dataset@YYYYMMDDTHHMMSS (if the dataset part does not exists only the YYYYMMDDTHHMMSS portion is kept)
+
 
+
== Approach #1: manual configuration ==
+
 
+
Portage scans a file (let says /etc/portage/fssnaps to be compliant with coming 1.0 profiles and unified configuration files) which describes what are the subvolumes to snapshot before doing a transaction:
+
  
 
<pre>
 
<pre>
/
+
Subsystem      sftp    internal-sftp
/usr
+
 
</pre>
 
</pre>
  
== Approach #2: automatic configuration ==
+
Now the $100 question: ''"how can OpenSSH can be told to restrict a user access to a simple sftp session?"'' Simple! Assuming that ''sftponly'' is the group you use for for your restricted users, just add to the file '''/etc/sshd/sshd_config''' the following statement:
  
Portage scans what lies in /etc/fstab that has been defined as btrfs or zfs or anything of the same kind. If an entry describe something is located in a "well-known" directory (e.g. /lib, /usr ....) it is included in the subvolumes list that have been to be snapshotted. To allow a bit of flexibility, a list of exclusion can be specied via a variable like EXEMPT_FROM_SNAPHOT="/lib /var". This is dangerous but could be needed in some contexts.
+
<pre>
 +
# Restricted users, no TCP connexions bouncing, no X tunneling.
 +
Match group sftponly
 +
        ChrootDirectory /home/%u
 +
        X11Forwarding no
 +
        AllowTcpForwarding no
 +
        ForceCommand internal-sftp
 +
</pre>
  
= Known Linux distros with the concept =
+
To understand how it works, you must be aware that, when you open an SSH session, the SSHD process launch a process on the server side which could be:
 +
* a shell => ssh login@host
 +
* a kind of dedicated ftp daemon (sftp-server) => sftp user@host
  
* So far Fedora is working on integrating BTRFS with Yum. [https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs]
+
TBC
* Ubuntu - [http://packages.ubuntu.com/us/oneiric/apt-btrfs-snapshot]
+
  
[[Category:Internals]]
+
[[Category:HOWTO]]
[[Category:Labs]]
+
[[Category:Portage]]
+
[[Category:FLOP]]
+

Revision as of 16:50, 30 August 2011

Context

In some cases, it can be useful to set up an access on your Funtoo box such as a user:

  • does not see the whole contents of the machine but, instead, remains "jailed" in a home directory
  • is able to transfer files back and forth on the box via SFTP
  • does not have access to a shell

Such a SFTP only access is easy to setup:

  1. Assign a group (e.g. sftponly) to users that must be restricted to a SFTP-only account
  2. Change a bit the configuration of OpenSSH so that users belonging to your sftp-only group are given a chrooted access
  3. Make OpenSSH ignore any other command than running sftp-server on the server side for users belonging to your sftp-only group (this is where the trick lies !)

Quick start

First, a dedicated group must be created. For the sake of the example we use sftponly here, use whatever name fits your preferences:

# groupadd sftponly

Next in the configuration of OpenSSH (located in /etc/sshd/sshd_config) locate:

Subsystem      sftp    /usr/lib64/misc/sftp-server

and change it for:

Subsystem      sftp    internal-sftp

Now the $100 question: "how can OpenSSH can be told to restrict a user access to a simple sftp session?" Simple! Assuming that sftponly is the group you use for for your restricted users, just add to the file /etc/sshd/sshd_config the following statement:

# Restricted users, no TCP connexions bouncing, no X tunneling.
Match group sftponly
        ChrootDirectory /home/%u
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp

To understand how it works, you must be aware that, when you open an SSH session, the SSHD process launch a process on the server side which could be:

  • a shell => ssh login@host
  • a kind of dedicated ftp daemon (sftp-server) => sftp user@host

TBC