3

I have got a specific folder located in "/home/.../reboot/". I have a series of users that require read-only access to the ever changing files within. My problem is that the same users are not authorized to view any of the parent directory files.

Right now, the only thing I have in place is that their starting folder is at "/home/.../reboot/" by changing the etc/passwd file; and I need to block all access to other folders. How could I only give them access to this directory?

  • setfacl i think is what you're looking for – h3rrmiller Oct 3 '12 at 19:55
  • Is there a good reason for maintaining files like that in a user's home directory? I should think because the files need to be used by many it would belong somewhere in /var/ or /usr/ where it could be owned by the same user, and readable to everyone else without special consideration and being more consistent with how other files work. – Centimane May 17 '17 at 11:06
3

For the record, alternatives to bindfs are aufs, unionfs-fuse and rofs. Of those aufs is the only one that is not fuse based.

All, (including aufs and bindfs) have limitations like not supporting ACLs (you can list them, but they're not in effect). Another alternative if you need ACLs is to use NFS.

3

Create a read-only view of that directory in a different location. You can do that with bindfs.

Let's say that the directory in question is /home/confidential/reboot and that you want to give read-only access to the users in the group mygroup. Create a directory /views/mygroup/reboot which is accessible to that group.

mkdir -p /views/mygroup/reboot
chown root:mygroup /views/mygroup
chmod 750 /views/mygroup

Create the read-only view with bindfs. The bindfs process must have the permission to read the files and to access the mount point; here you would presumably run it as root.

bindfs -p a-w /home/confidential/reboot /views/mygroup/reboot

If the files under /home/confidential/reboot are not readable by the users in mygroup and you want to make them so, change the permissions specification to -p a=rX.

To create the read-only view at boot time, add it to /etc/fstab:

bindfs#/home/confidential/reboot /views/mygroup/reboot fuse perms=a=rX
  • actually just mount --bind can switch bounded content to RO, IIRC. – poige Oct 17 '12 at 20:31
  • @poige There's been a patch for that for a very long time, but last I looked it hadn't been accepted in the mainstream kernel. Has it now? Since when? – Gilles 'SO- stop being evil' Oct 17 '12 at 20:34
  • dunno exactly. See: mkdir /tmp/ro && mount -r --bind /etc /tmp/ro && touch /tmp/ro/TOUCH; umount /tmp/ro; uname -r → touch: cannot touch '/tmp/ro/TOUCH': Read-only file system 2.6.32-042stab057.1` (It's RHEL's version + OpenVZ patches) – poige Oct 17 '12 at 20:54
  • @poige Working on Debian squeeze too. But I'm not sure if it's because our distributions have applied the patch. Bindfs also has the advantage of showing up as a separate filesystem, so you can exclude it from backups and the like. The downside is slightly reduced performance. – Gilles 'SO- stop being evil' Oct 17 '12 at 21:02
  • @poige I just checked on Ubuntu 12.04, mount --bind -r from a read-write filesystem produces a read-write access point. Mount warns me mount: warning: /tmp/ro seems to be mounted read-write., and that is indeed the case. So don't rely on it unless you know your (distribution's) kernel has the patch. – Gilles 'SO- stop being evil' Oct 18 '12 at 9:32
-3
  1. If a directory doesn't have Read Permission, corresponding users wont'be able to get list of files inside it, and, therefore, access it.
  2. You can use ACLs (man setfacl)
  • ACLs won't help: no matter how it's done, if a user can't access a directory, they can't access the directories underneath either. Also, regarding your first point: if users has execute permission on the directory, they can access files in the directory: they can't enumerate the files but they can access a file if they know or guess its name. – Gilles 'SO- stop being evil' Oct 18 '12 at 9:34
  • @Gilles, Regarding #1 — it's dependent on requirements and environment — somewhere that would suffice, somewhere you'd need to set per-file access mode or -x on a dir in the path. And to the #2 — are we talking bout directory access or file access? – poige Oct 18 '12 at 11:48
  • No, #1 works the same on every unix. If users are not allowed to access a directory, then they are not allowed to access files underneath it, no matter what the permissions on the files are. ACLs might help to give these users execute permissions on the directory while not giving them more permissions than they should have, but it's a far cry from the concept to the implementation; it's likely to result in hard-to-maintain permissions. – Gilles 'SO- stop being evil' Oct 18 '12 at 12:10
  • What do you mean by "not allowed to access a directory"? And what relation to #1 it has? I said somewhere it could be okay just to hide listing of files. – poige Oct 18 '12 at 12:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.