From: Tyler Hicks <tyhicks@canonical.com>
To: Ray Van Dolson <rvandolson@esri.com>
Cc: ecryptfs@vger.kernel.org
Subject: Re: Active Directory Integration?
Date: Tue, 29 May 2012 17:01:19 -0700 [thread overview]
Message-ID: <20120530000119.GA19846@boyd> (raw)
In-Reply-To: <20120529225104.GA4091@esri.com>
[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]
On 2012-05-29 15:51:04, Ray Van Dolson wrote:
> Hello;
>
> I'm exploring using eCryptfs in tandem with Samba, winbindd and Active
> Directory to automount eCryptfs-encrypted directores automatically
> based on the AD user accessing it.
>
> Is anyone out there doing something similar or am I barking up the
> wrong tree here?
You're not barking up the wrong tree. I recall this idea popping up in a
few different designs over the years. Unfortunately, no one has
committed the development resources to make it work.
I'm making the assumptions that you're wanting to mount eCryptfs on top
of a SMB client, that the client is the in-kernel CIFS code, and that
you'll pull the key material for the eCryptfs mount from the directory
store. Let me know if any of those assumptions are invalid.
I haven't tested it recently, but eCryptfs is not known to work on top
of the in-kernel CIFS client code. It is worth a shot trying. Please
report any bugs you discover. It may have benefited from some of the
bugs I fixed (about a year ago) when trying to use eCryptfs on top of
the in-kernel NFS client.
Additionally, I don't know of an off-the-shelf way to fetch an eCryptfs
mount passphrase from AD and insert it into the kernel keyring in
preparation for doing the eCryptfs mount. It should just be a matter of
some glue code but no one, that I'm aware of, has done it.
> In addition, this conceptually makes sense to me from a 1:1 user to
> directory or share perspective, but when multiple users are allowed
> access to a file system it's not quite so clear how the implementation
> would look (or even if it would be doable).
eCryptfs lacks the ability to do even slightly complex decision making
about what key should be used when encrypting a new file. Currently, it
is done with just a list of key signatures specified at mount time.
eCryptfs does have some basic support for allowing multiple keys to be
used to access a given file. However, it would be difficult to do if
users are accessing the shares from different client machines because
each client would need to have all of the keys loaded into the kernel
keyring. That is obviously not ideal. :/
Tyler
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2012-05-30 0:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-29 22:51 Active Directory Integration? Ray Van Dolson
2012-05-30 0:01 ` Tyler Hicks [this message]
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=20120530000119.GA19846@boyd \
--to=tyhicks@canonical.com \
--cc=ecryptfs@vger.kernel.org \
--cc=rvandolson@esri.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox