EcryptFS development
 help / color / mirror / Atom feed
* Ecryptfs over sshfs and timestamps
@ 2013-04-21 10:30 Ivan Yosifov
  2013-04-21 20:32 ` Christian Kujau
  0 siblings, 1 reply; 9+ messages in thread
From: Ivan Yosifov @ 2013-04-21 10:30 UTC (permalink / raw)
  To: ecryptfs

Hi all,

I'm trying to use ecrypts on top of an sshfs mount for remote backup
to an untrusted machine. I'm having a problem with timestamps however:

$ cp -a file.txt bak/
cp: preserving times for ‘bak/file.txt’: Operation not permitted

rsync -a is giving a similar error too, but cp -a to the underlying
sshfs works. Any help would be much appreciated.

Thanks,
Ivan Yosifov

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Ecryptfs over sshfs and timestamps
  2013-04-21 10:30 Ecryptfs over sshfs and timestamps Ivan Yosifov
@ 2013-04-21 20:32 ` Christian Kujau
       [not found]   ` <CAM-DUcOrs3vws+Vt9BWw29da8M_1LRwkrPHPF_eUc3Mz2a7ZaQ@mail.gmail.com>
  0 siblings, 1 reply; 9+ messages in thread
From: Christian Kujau @ 2013-04-21 20:32 UTC (permalink / raw)
  To: Ivan Yosifov; +Cc: ecryptfs

On Sun, 21 Apr 2013 at 13:30, Ivan Yosifov wrote:
> I'm trying to use ecrypts on top of an sshfs mount for remote backup
> to an untrusted machine. I'm having a problem with timestamps however:

Nice setup. I had to try this and it's working here:

sid0# sshfs root@localhost:/mnt/disk/enc /mnt/disk/sshfs
root@localhost's password:

sid0# mount -t ecryptfs /mnt/disk/sshfs /mnt/disk/dec
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=14f4412383d9220f
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=14f4412383d9220f
Mounted eCryptfs

sid0# cd /mnt/disk/dec
sid0# cp -a lib/dpkg/ bak
sid0# diff -r lib/dpkg/ bak/


sid0# uname -a
Linux sid0 3.8-trunk-amd64 #1 SMP Debian 3.8-1~experimental.1 x86_64 GNU/Linux

sid0# dpkg -l | egrep 'ecryptfs|sshfs' | cut -c-80
ii  ecryptfs-utils                             103-2
ii  libecryptfs0                               103-2
ii  sshfs                                      2.4-1

Only extended attributes do not seem to be supported. What versions are 
you on? Does strace(1) reveal something useful?

Christian.
-- 
BOFH excuse #340:

Well fix that in the next (upgrade, update, patch release, service pack).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Ecryptfs over sshfs and timestamps
       [not found]   ` <CAM-DUcOrs3vws+Vt9BWw29da8M_1LRwkrPHPF_eUc3Mz2a7ZaQ@mail.gmail.com>
@ 2013-04-21 23:29     ` Christian Kujau
  2013-04-23 19:11       ` Ivan Yosifov
  0 siblings, 1 reply; 9+ messages in thread
From: Christian Kujau @ 2013-04-21 23:29 UTC (permalink / raw)
  To: Mike Reinstein; +Cc: Ivan Yosifov, ecryptfs

On Sun, 21 Apr 2013 at 13:54, Mike Reinstein wrote:
> Maybe I'm just misunderstanding the problem. Is it being suggested that the
> unencrypted copy of the data should be backed up over sshfs to an untrusted
> machine?

No, I think the untrusted machine would hold the encrypted data, which is 
mounted to a trusted machine, where it's then decrypted via ecryptfs. In 
my example:

>> sid0# sshfs root@localhost:/mnt/disk/enc /mnt/disk/sshfs
>> root@localhost's password:

Here, localhost (untrusted) will hold the encrypted content in 
/mnt/disk/enc, which is now mounted on a trusted machine, still encryted:

sid0# ls -go /mnt/disk/sshfs/
total 32
drwx------ 1 12288 Apr 21 13:16 ECRYPTFS_FNEK_ENCRYPTED.FWYIx22XUxYW1kS.8RBEqYi.2ckHIID6ncewGoCHUK9KZiv5Ci99Q9LW3E--

>> sid0# mount -t ecryptfs /mnt/disk/sshfs /mnt/disk/dec

The decryption is done on the trusted machine. Maybe my example is kinda 
confusing because I'm using "localhost" as the "untrusted remote machine". 
But if you replace "localhost" with "evilhost", it should be clearer.

C.
-- 
BOFH excuse #353:

Second-system effect.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Ecryptfs over sshfs and timestamps
  2013-04-21 23:29     ` Christian Kujau
@ 2013-04-23 19:11       ` Ivan Yosifov
  2013-04-23 19:30         ` Tyler Hicks
  0 siblings, 1 reply; 9+ messages in thread
From: Ivan Yosifov @ 2013-04-23 19:11 UTC (permalink / raw)
  To: Christian Kujau; +Cc: Mike Reinstein, ecryptfs

On Mon, Apr 22, 2013 at 2:29 AM, Christian Kujau <lists@nerdbynature.de> wrote:
> On Sun, 21 Apr 2013 at 13:54, Mike Reinstein wrote:
>> Maybe I'm just misunderstanding the problem. Is it being suggested that the
>> unencrypted copy of the data should be backed up over sshfs to an untrusted
>> machine?
>
> No, I think the untrusted machine would hold the encrypted data, which is
> mounted to a trusted machine, where it's then decrypted via ecryptfs.

You're right, that's the idea. I want to run the crypto on the trusted
machine and only use the untrusted one as dumb storage.

I'm running arch, ecryptfs-utils 103, sshfs 2.4, kernel 3.8.8, so very
similar to yours. Running strace was a good idea, the relevant bit is:

utimensat(4, NULL, {{1366539595, 699650012}, {1366539595, 699650012}},
0) = -1 EPERM (Operation not permitted)

The setup that fails is thus: The sshfs is mounted by my regular user
with -o allow_root and the ecryptfs is mounted from a root console.

I tried doing both the sshfs and ecryptfs mounts by root and that
worked. I'm assuming it's a problem if the sshfs and ecryptfs are
"running as different users". Frankly, I'm not at all sure what
"running as a user" means in the context of kernel code like fuse and
ecryptfs, does this ring any bells?

Are both mounts in your setup done by a non-root user? If yes, what's
the correct way to mount an ecryptfs as a user? I tried adding a line
to /etc/fstab with <all the options>,user,noauto and it didn't work.
The arch wiki (
https://wiki.archlinux.org/index.php/ECryptfs#Mounting_.28the_hard_way.29
) suggests /sbin/mount.ecryptf should be suid root, but that doesn't
make it work either.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Ecryptfs over sshfs and timestamps
  2013-04-23 19:11       ` Ivan Yosifov
@ 2013-04-23 19:30         ` Tyler Hicks
  2013-04-24 18:45           ` Ivan Yosifov
  0 siblings, 1 reply; 9+ messages in thread
From: Tyler Hicks @ 2013-04-23 19:30 UTC (permalink / raw)
  To: Ivan Yosifov; +Cc: Christian Kujau, Mike Reinstein, ecryptfs

[-- Attachment #1: Type: text/plain, Size: 2303 bytes --]

On 2013-04-23 22:11:40, Ivan Yosifov wrote:
> On Mon, Apr 22, 2013 at 2:29 AM, Christian Kujau <lists@nerdbynature.de> wrote:
> > On Sun, 21 Apr 2013 at 13:54, Mike Reinstein wrote:
> >> Maybe I'm just misunderstanding the problem. Is it being suggested that the
> >> unencrypted copy of the data should be backed up over sshfs to an untrusted
> >> machine?
> >
> > No, I think the untrusted machine would hold the encrypted data, which is
> > mounted to a trusted machine, where it's then decrypted via ecryptfs.
> 
> You're right, that's the idea. I want to run the crypto on the trusted
> machine and only use the untrusted one as dumb storage.
> 
> I'm running arch, ecryptfs-utils 103, sshfs 2.4, kernel 3.8.8, so very
> similar to yours. Running strace was a good idea, the relevant bit is:
> 
> utimensat(4, NULL, {{1366539595, 699650012}, {1366539595, 699650012}},
> 0) = -1 EPERM (Operation not permitted)

Does this happen when only using sshfs (without eCryptfs mounted on
top)?

Does this happen when only using eCryptfs (mounted locally on top of
something like ext4)?

> 
> The setup that fails is thus: The sshfs is mounted by my regular user
> with -o allow_root and the ecryptfs is mounted from a root console.
> 
> I tried doing both the sshfs and ecryptfs mounts by root and that
> worked. I'm assuming it's a problem if the sshfs and ecryptfs are
> "running as different users". Frankly, I'm not at all sure what
> "running as a user" means in the context of kernel code like fuse and
> ecryptfs, does this ring any bells?

Nothing like that should be a problem from eCryptfs' standpoint. I have
no idea about sshfs.

> 
> Are both mounts in your setup done by a non-root user? If yes, what's
> the correct way to mount an ecryptfs as a user? I tried adding a line
> to /etc/fstab with <all the options>,user,noauto and it didn't work.
> The arch wiki (
> https://wiki.archlinux.org/index.php/ECryptfs#Mounting_.28the_hard_way.29
> ) suggests /sbin/mount.ecryptf should be suid root, but that doesn't
> make it work either.

Don't set mount.ecryptfs as setuid root. That's very bad advice.

Why didn't adding user,noauto to the fstab entry work for you? What
error message did you see? Anything relevant in the system log?

Tyler

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Ecryptfs over sshfs and timestamps
  2013-04-23 19:30         ` Tyler Hicks
@ 2013-04-24 18:45           ` Ivan Yosifov
  2013-04-24 18:59             ` Ivan Yosifov
  0 siblings, 1 reply; 9+ messages in thread
From: Ivan Yosifov @ 2013-04-24 18:45 UTC (permalink / raw)
  To: Tyler Hicks; +Cc: Christian Kujau, Mike Reinstein, ecryptfs

> Does this happen when only using sshfs (without eCryptfs mounted on
> top)?

No, cp --preserve=timestamps to sshfs alone works.

> Does this happen when only using eCryptfs (mounted locally on top of
> something like ext4)?

No, cp --preserve=timestamps to ecryptfs on top of ext4 works too.

> Nothing like that should be a problem from eCryptfs' standpoint. I have
> no idea about sshfs.

Well, the existence of the allow_root and allow_other sshfs options
suggest sshfs somehow cares.

> Why didn't adding user,noauto to the fstab entry work for you? What
> error message did you see? Anything relevant in the system log?

For example, I just tried with the following line (the key '1' is
obviously just for testing):

/home/obelix/evil_host /home/obelix/bak ecryptfs
user,noauto,verbose,key=passphrase:passphrase_passwd=1 0 0

I got:

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Ecryptfs over sshfs and timestamps
  2013-04-24 18:45           ` Ivan Yosifov
@ 2013-04-24 18:59             ` Ivan Yosifov
  2013-04-29  1:27               ` Tyler Hicks
  0 siblings, 1 reply; 9+ messages in thread
From: Ivan Yosifov @ 2013-04-24 18:59 UTC (permalink / raw)
  To: Tyler Hicks; +Cc: Christian Kujau, Mike Reinstein, ecryptfs

Sorry, the mail got sent incomplete, resending:

> Does this happen when only using sshfs (without eCryptfs mounted on
> top)?

No, cp --preserve=timestamps to sshfs alone works.

> Does this happen when only using eCryptfs (mounted locally on top of
> something like ext4)?

No, cp --preserve=timestamps to ecryptfs on top of ext4 works too.

> Nothing like that should be a problem from eCryptfs' standpoint. I have
> no idea about sshfs.

Well, the existence of the allow_root and allow_other sshfs options
suggest it somehow cares.

> Why didn't adding user,noauto to the fstab entry work for you? What
> error message did you see? Anything relevant in the system log?

For example, I just tried with the following line (the key '1' is
obviously just for testing):

/home/obelix/evil_host /home/obelix/bak ecryptfs
user,noauto,verbose,key=passphrase:passphrase_passwd=1 0 0

I got:

$ mount ./bak
Exiting. Unable to obtain passwd info

I didn't get anything written to /var/log/messages.log or dmesg.

If I run the mount as root, I get asked for the other parameters and
in the end it mounts.
I tried with a more comprehensive fstab line too:

/home/obelix/evil_host /home/obelix/bak ecryptfs
user,noauto,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,verbose,key=passphrase:passphrase_passwd=1,ecryptfs_passthrough,ecryptfs_enable_filename_crypto=n
0 0

This mounts as root without asking any questions and fails as user
with the same error.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Ecryptfs over sshfs and timestamps
  2013-04-24 18:59             ` Ivan Yosifov
@ 2013-04-29  1:27               ` Tyler Hicks
  2013-05-03  6:55                 ` Ivan Yosifov
  0 siblings, 1 reply; 9+ messages in thread
From: Tyler Hicks @ 2013-04-29  1:27 UTC (permalink / raw)
  To: Ivan Yosifov; +Cc: Christian Kujau, Mike Reinstein, ecryptfs

[-- Attachment #1: Type: text/plain, Size: 2196 bytes --]

On 2013-04-24 21:59:05, Ivan Yosifov wrote:
> Sorry, the mail got sent incomplete, resending:
> 
> > Does this happen when only using sshfs (without eCryptfs mounted on
> > top)?
> 
> No, cp --preserve=timestamps to sshfs alone works.
> 
> > Does this happen when only using eCryptfs (mounted locally on top of
> > something like ext4)?
> 
> No, cp --preserve=timestamps to ecryptfs on top of ext4 works too.
> 
> > Nothing like that should be a problem from eCryptfs' standpoint. I have
> > no idea about sshfs.
> 
> Well, the existence of the allow_root and allow_other sshfs options
> suggest it somehow cares.
> 
> > Why didn't adding user,noauto to the fstab entry work for you? What
> > error message did you see? Anything relevant in the system log?
> 
> For example, I just tried with the following line (the key '1' is
> obviously just for testing):
> 
> /home/obelix/evil_host /home/obelix/bak ecryptfs
> user,noauto,verbose,key=passphrase:passphrase_passwd=1 0 0
> 
> I got:
> 
> $ mount ./bak
> Exiting. Unable to obtain passwd info
> 
> I didn't get anything written to /var/log/messages.log or dmesg.
> 
> If I run the mount as root, I get asked for the other parameters and
> in the end it mounts.
> I tried with a more comprehensive fstab line too:
> 
> /home/obelix/evil_host /home/obelix/bak ecryptfs
> user,noauto,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,verbose,key=passphrase:passphrase_passwd=1,ecryptfs_passthrough,ecryptfs_enable_filename_crypto=n
> 0 0
> 
> This mounts as root without asking any questions and fails as user
> with the same error.

It is typically easier to manually perform the mount once, then take
note of the mount options listed in /proc/mounts, add an entry to fstab,
then bypass the eCryptfs mount helper when performing mounts.

So, your fstab entry might look something like this:

/tmp/ecryptfs /tmp/ecryptfs ecryptfs ecryptfs_sig=253ca7e88811d184,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,defaults,users,noauto 0 0

Adjust the ecryptfs_sig= value accordingly.

Now, do a mount that bypasses the eCryptfs mount helper by using the -i
mount option.

$ mount -i /tmp/ecryptfs

Tyler

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Ecryptfs over sshfs and timestamps
  2013-04-29  1:27               ` Tyler Hicks
@ 2013-05-03  6:55                 ` Ivan Yosifov
  0 siblings, 0 replies; 9+ messages in thread
From: Ivan Yosifov @ 2013-05-03  6:55 UTC (permalink / raw)
  To: Tyler Hicks; +Cc: Christian Kujau, Mike Reinstein, ecryptfs

Thanks, it works now. I was calling just "mount" as a user and not
"mount -i", it works with "mount -i".

I ultimately tracked down the utimensat(...) = EPERM problem to a
UID/GID mismatch between my machine and the remote one.
My local user is 1000:1000, the remote one is 1001:1001. When I just
mount the sshfs, I see all remote files as 1001:1001.
I can still access all of them, including the -rw------- (600) ones,
but apparently ecryptfs doesn't like this setup.

When I mount the ecryptfs lower dir with sshfs ... -o uid=1000 -o
gid=1000, cp --preserve=timestamps works, it doesn't matter
if I mount the ecryptfs on top as root (mounting as root requries
sshfs ... -o allow_root) or as the user.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2013-05-03  6:55 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-21 10:30 Ecryptfs over sshfs and timestamps Ivan Yosifov
2013-04-21 20:32 ` Christian Kujau
     [not found]   ` <CAM-DUcOrs3vws+Vt9BWw29da8M_1LRwkrPHPF_eUc3Mz2a7ZaQ@mail.gmail.com>
2013-04-21 23:29     ` Christian Kujau
2013-04-23 19:11       ` Ivan Yosifov
2013-04-23 19:30         ` Tyler Hicks
2013-04-24 18:45           ` Ivan Yosifov
2013-04-24 18:59             ` Ivan Yosifov
2013-04-29  1:27               ` Tyler Hicks
2013-05-03  6:55                 ` Ivan Yosifov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox