From: Tyler Hicks <tyhicks@canonical.com>
To: Ivan Yosifov <iyosifov@gmail.com>
Cc: Christian Kujau <lists@nerdbynature.de>,
Mike Reinstein <reinstein.mike@gmail.com>,
ecryptfs@vger.kernel.org
Subject: Re: Ecryptfs over sshfs and timestamps
Date: Tue, 23 Apr 2013 12:30:16 -0700 [thread overview]
Message-ID: <20130423193016.GB7389@boyd> (raw)
In-Reply-To: <CAHHtCV8Efp+OJ3Rx54_d_dMcSvZnNxdodBK96hSj9=1iLUSB7g@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2013-04-23 19:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130423193016.GB7389@boyd \
--to=tyhicks@canonical.com \
--cc=ecryptfs@vger.kernel.org \
--cc=iyosifov@gmail.com \
--cc=lists@nerdbynature.de \
--cc=reinstein.mike@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.