One useful apppplication for Linux bind mounts, includes jail-chroot
scenario by which there are multiple
sub-directories ("folders") of an htdocs site directory mapped to a
single chroot directory which is exposed via
ftp/sftp to a single user, or class of users (with particular access
requirement who are all chroot to the same dir).
This is called a ROLE and is feature present in popular commercial
ftpd. It can be implemented in all recent Linux
distro's oss ftpd, such as proftpd or vsftpd and openssh sftp-server.
This is especially useful:
---
A) Where there is desired, a flat group structure and permissions
per-site/client on a host. Each client site/vhost has
multiple users: admins and ftp users with specific delegated
publishing rights. All site files have uniform ownership.
B) When users should not be granted read access to files at paths with
group||other read permissions. That is they
should not descend paths, other than those for which they are granted
to update and are responsible for (those
bound to their Publishing ROLE by the site admin).
Such users can only login to the server via an SFTP and/or FTP
chroot'ed environment, and never see files except
those under their chrooted home. They do not get access the system
root(/) fs or full SSH shell rights. Thus a "vhost"
directory structure mirroring that of the site web root is made
available, where the path of chroot dir is descended the
same as in the client web root from the absolute root of the server.
Only those files and directories for which delegsted rights appear in
the FTP client listing for a particular user who logs
into the remote web server. Since these map one:one to dir/files
under htdocs, there is no mistake which files point
where for both chroot and httpd vhost, same as full privileged site
admin users. Site admins can see the enite server
root file system and site htdocs, including all bound mounts from the
user chroots as though they are part of the
htdocs directory structure to begin with, because for userspace
process they are in the vfs directory as bound.
Example:
---
Site: /srv/www/websmiths.ca/
Site cgi-bin: /srv/www/websmiths.ca/cgi-bin
Site htdocs: /srv/www/websmiths.ca/htdocs
Site admin user: websmith
Site group: websmith
Delegated paths:
/srv/www/websmiths.ca/ (full chroot)
Site user: storefront
Site group: websmith
Delegated paths:
Chroot: /users/storefront
1. /users/storefront/cgi-bin =>
/srv/www/websmiths.ca/cgi-bin
2. /users/storefront/htdocs/store =>
/srv/www/websmiths.ca/htdocs/store
3. /users/storefront/htdocs/cart =>
/srv/www/websmiths.ca/htdocs/cart
Site user: promo
Site group: websmith
Delegated paths:
1. /users/promo/htdocs/css =>
/srv/www/websmiths.ca/htdocs/css
2. /users/promo/htdocs/catalogue =>
/srv/www/websmiths.ca/htdocs/catalogue
3. /users/promo/htdocs/deals =>
/srv/www/websmiths.ca/htdocs/deals
- User:websmiths can see and change all site section as site admin.
- User:promo cannot see htdocs/cart or update the store-front visa ccv scripts
- User:storefront cannot update css or main site pages such as
legal-privacy, but can upload cart and store
dynamic html pages plus their supporting cgi-bin scripts
- No user except websmith can overwrite the whole site or
publish/delete sections, even if they are in the same
group as some site sections or all sections are group writeable.
When promo logs in via FTP to remote server, in order to update
style-sheets, the admin can tell them to use
path: /htdocs/css and their remote client will point to the same
files listed by ssh in the admins sftp. This
behaviour needs to be twesked slightly when an admin account has full
shell access, user chroot would then
list /users/promo/srv/www/websmiths.ca/htdocs/css/ and in S/FTP client
User:promo sees:
---
Remote directory: /
LIST
.
..
.ssh
.profile
srv/
CHDIR /srv/www/websmiths.ca/htdocs/css/
LIST
.
..
main.css
layout.css
promo_04.css
(cwd of ftpd: /users/promo/srv/www/websmiths.ca/htdocs/css/)
Web browser sees:
---
http://www.websmiths.ca/index.html?lang=eng
http://www.websmiths.ca/css/main.css
http://www.websmiths.ca/promo/dec13?cat=bound_mntpnt
http://www.websmiths.ca/catalogue/?item=widget+mntpnt (add it to
cart and check-out)
https://store.websmiths.ca/css/main.css (just an example. Not my domain)
https://store.websmiths.ca/cgi-bin/order?id=672987
How it works:
--
mount --bind /path/to/original/directory /path/to/mountpoint
/etc/fstab:
#lists each bound mount-point for chroot access
/path/to/original/directory /path/to/mountpoint none bind 0 0
#lists each /users/webroot lvm file system or mounts main /users fs
with group quota
/dev/mapper/client-data /users ext3 defaults 0 0
This application maps multiple directories rooted under one chroot to
point to paths under the htdocs which
appear as bound mount-points. Collectively multiple users build up
and maintain the master site from
delegated site-sections ("folders"). The site admin maintains master
site layout and index pages. Site admin adds
or removes sections and requests them bound to specific user's chroot
by tbe hosting sysadmin/via cpanel.
>From a management standpoint certain roles/access accounts only get
access to a specific folder of the site, easy
for web masters to recall.
Slight detractor:
---
A) Bit more work to setup/support. But good results for hosted clients.
B) What it cannot handle is mapping a path into multiple chroot since
the files actually reside in the users chroot dir, and are bound under
htdocs site directory to the path they
appear to the web server. Thus one chroot per group/role makes sense.
The correct answer for this situation of binding multiple chroot()ed
users to publish to a single path is to
instead use a new common group and directory as usual, but chrooting
them higher-up into the site -- this
doesn't need bound mntpnt if it can be accomodated. However: Can it
be setup by binding the path in the
opposite direction. That is left as an excercise for the reader, does
it work binding *into* a chroot? (instead
of from)
C) With containers, specific httpd instances can be fired-up per
client providing similar isolation to jailed chroot
on a shared web host, however this approach still doesn't address
roles/access rights at a finer granularity with-in
the same server, if unix account owner+permissions do not suffice.
It is easier to have single chroot to mask file acccess than to audit
permissions/acls for numerous varied:
user-group membership and modes, though typically in simple site
scenarios there is no reason to deviate to
bound mounts, when umask and user-groups make sense to begin with,b y
choosing a common user:group to
own webroot. Only as more complex roles/permissions appear is it
convenient to have chroot jailing to bound
mounts. Despite the required lines in fstab, it may be possible to
allow unprivileged bind using a front-end per-site.
Regardless: ftp can have only the primary group of users account to
write; therefore outside bound chroot; if more
than one group is needed, user cannot use secondary group to write in
regular ftpd and file owner at write is not
based on shell group access. That is a reason to perhaps extend
vsftpd to auto-compose role based folder access
based on chroot and binds much as in httpd alias set-up path to
multiple directory in vhost.. rather than require the
admin to bind these manually. Vsftpd already understands the Linux
chroot, so it's not a far off patch.
For now, seems the canonical approach is to use mount command as detailed below.
See Also:
---
http://askubuntu.com/questions/33421/give-ftp-users-access-to-directories-outside-their-root-using-symlinks
Thx,
Allan Fields
Himeji Systems, Inc.
Ottawa, Canada
----------------------------------------------
Message: 1
Date: Thu, 26 Dec 2013 12:33:03 -0500
From: Bart Trojanowski
To: "Robert P. J. Day"
Cc: linux [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca
Subject: Re: [OCLUG-Tech] a compelling application for bind mounts?
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1
Similar to chroots, I use bind mounts for containers. This is useful to
give all containers access to the same /home or for distributing
/etc/resolv.conf. The latter is actually a very cool use case of bind
mounts... you can bind a file, not just a directory.
--
Sent from my Nexus 4.
On Dec 26, 2013 10:10 AM, "Strake" wrote:
> On 26/12/2013, Robert P. J. Day wrote:
> > does anyone here use bind mounts on a regular basis, and for what?
>
> Not regular, but I often bind into chroot environments or with HTTP
> servers who won't follow symlinks for security reasons.
> _______________________________________________
> Linux mailing list
> Linux [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca
> http://oclug.on.ca/mailman/listinfo/linux
>