Files – Still Able to Read File After Changing Permissions

This answer works on Debian (tested on lenny and squeeze). After investigation, it seems to work only thanks to a Debian patch; users of other distributions such as Ubuntu may be out of luck.

You can use mount --bind. Mount the “real” filesystem under a directory that's not publicly accessible. Make a read-only bind mount that's more widely accessible. Make a read-write bind mount for the part you want to expose with read-write access.

mkdir /media/hidden /media/hidden/sdz99
chmod 700 /media/hidden
mount /dev/sdz99 /media/hidden/sdz99
mount -o bind,ro /media/hidden/sdz99/world-readable /media/world-readable
mount -o bind /media/hidden/sdz99/world-writable /media/world-writable

In your use case, I think you can do:

mkdir /var/smb/hidden
mv /var/smb/snapshot /var/smb/hidden
mkdir /var/smb/snapshot
chmod 700 /var/smb/hidden
chmod 755 /var/smb/hidden/snapshot
mount -o bind,ro /var/smb/hidden/snapshot /var/smb/hidden/snapshot

I.e. put the real snapshot directory under a restricted directory, but give snapshot read permissions for everyone. It won't be directly accessible because its parent has restricted access. Bind-mount it read-only in an accessible location, so that everyone can read it through that path.

(Read-only bind mounts only became possible several years after bind mounts were introduced, so you might remember a time when they didn't work. I don't know offhand since when they work, but they already worked in Debian lenny (i.e. now oldstable).)

The /sys (sysfs) filesystem is somewhat special; many operations are not possible, for example creating or removing a file. Changing the permissions and ownership of a file or setting an ACL is permitted; that allows the system administrator to allow certain users or groups to access certain kernel entry points.

There is no special case that restricts a file that's initially read-only for everyone from being changed to being writable for some. That's what Vim does when it is thwarted in its initial attempt to save.

The permissions are the only thing that prevent the file from being written. Thus, if they're changed, the file content changes, which for a module parameter changes the parameter value inside the module.

Normally this doesn't have any security implication since only root can change the permissions on the file and root can change the value through /dev/kmem or by loading another module. It's something to keep in mind if root is restricted from loading modules or accessing physical memory directly by a security framework such as SELinux; the security framework needs to be configured to forbid problematic permission changes under /sys. If a user is given ownership of the file, they'll be able to change the permissions; to avoid this, if a specific user needs to have permission to read a parameter, don't chown the file to that user, but set an ACL (setfacl -m u:alice:r /sys/…).