I have a NFS server sharing video’s.
I have created 4 user groups on my ldap server (kids, preteens,teens, parents).
My movies are assigned nobody.<ldap_group> such as nobody.teens.
My youngest child is a member of the kids group, but can still watch videos that are not assigned to the kids group.
What am I doing wrong?
Is it possible to hide files of other groups than your a member of?
John
A file can be read by everybody when it is made world readable. In your post you concentrate on group membership of a user. But when a files access bits are rw-r–r-- it can be read by everybody and only be written by the owner. When it is rw-rw-r–, it can also be written by the group. When it is rw-r-----, only owner and group memebers can read (and the owner can write).
Check this first
hcvv;
Yeah, I figured that out the hard way late last night. I set the files to 700, then added Group read which ended up -rwxr-----. I dont know if execute is really needed, but its there.
Now for my next trick, to make the files disappear so the kids only see files they can watch.
Thanks,
John
You should realy try to understand these things as they are crucial to your system’s security.
the x bit is only needed for
a) directories (where it means that you may ‘search’, or realy use them as directories).
b) files that are executable programs. That is absolute binaries as well as (shell) scripts.
As your videos are none of them the x-bit has no use there. And a general remark is, when not needed, do not use it.
When you make things readable for members of the group (as you did) everybody that can join that group (either by default at login or because other groups are linked to him) can read. So your kids should not be in the same group as the directories/files they may not see.
Something like:
. Kids files are owned by the group kids.
. Other files are owned by group adults.
. All users have as normal group either kids or adults (use YaST for this).
. When adults do like to see kids movies, add the group kids to that adult (or all adults) with YaST.
. Make all directories rwxr-x— and all files rw-r-----. You, as owner, could even remove all w-bits after the files are put int their place to protect against overwriting by error.
Success.
hcvv;
I guess I should have started off with all my kids computers use OpenSuSE 11.2. We have no windows on our network, with the rare exception of a VM needed for final testing of Word Doc’s to ensure formatting is correct.
My setup as what your suggesting. I have four groups stored in LDAP.
kids (under 10)
preteens (under 13)
teens (under 18)
parents (over 18)
All users are joined to the appropriate group and below. So my teen is joined to teen, preteen, & kids. Parents are joined to all 4 groups. I have yet to learn how to nest groups. Doesnt appear Yast allows you to do so with LDAP groups.
But when the kids open Dolphin and browse to /media/network/Video, they can see all 105 movies, when only 15 apply to them. It makes it hard for them to quickly determine which movie they can watch when they are always being denied access due to group member ship of the vast majority of movies. So if I could set it up so they only see the 15 movies they can watch without having to move the movies to a seperate folder called kids, that would be great.
Setting up some kinda filter so they can only see files of groups they are a member of would be the way to go. The folder view widget has the ability of filters, but it wont filter against group member ship only file typs. Too Bad.
BTW, I removed execute from my movies.
John
I know not much about LDAP. For distributed passwd/group files we used NIS. But I think in the end it is all the same.
When you have all the movies in /media/network/Video without any intermediate directories, everybody who has rx for the directory /media/network/Video can see all the files. You can do nothing about it. Moving the adult movies to /media/network/Video/adults, making adults the group of this directory (and everything below) and setting the access bits to r-x------ makes it impossible for the kids to look inside.
It is not that difficult to understand. You can either look inside a directory or not. That is what te access bits do.
An Example of how my structure is.
/media/network/Video/<video name>/video name.avi
Creating Catagory sub folder with in the Video folder is exactly what I dont want to do. I have sub folders for the the video names, but I dont want it broken down anyfurther. I dont want to know that Air Force One is located in preteen, James Bond is in Parents, & Fast and the Furious is in teen folder.
So it sounds like I am as close as I can be. I put in a feature request for the ability to filter by group membership. Maybe that will get picked up soon.
Thanks,
John
Though I will not discourage you, a feature to alter the behaviour of the access bits (in fact adding new bits) after more then this principle works for more then 30 years in all Unix/Linux systems and file systems isn’t something I see to be implemented soon.
A solution might be writing an interface (GUI applic?) that hides things away knowing who is the user and what is his group, but that will not refrain the user from using a normal file manager or the CLI to see it all.
I am not saying alter the access bit. Like you said, why change what has worked for so long so well.
In my feature request, I state how the folder view widget (uded in kde) can be configured to show the contents of a folder. One of the tabs is for filtering and you can show or hide based on file extension. Why not add the ability to filter based on group or ownership to that widget and to dolphin? Then its up to the user to add the widget to the desktop, and configure it to only show files that the owners group is apart of.
John
As I said, that is a filter inside some end-users tool (call it Dolphin or what you want). That can be made, like a filter not to show filenames with the character O three characters after a character h and that only on fridays It has nothing to do with securiry, as the title of your thread states. But otoh this case hasn’t much to do with NFS either.
You can create a Master directory group which the kids don’t belong to. Take read permission off it, but set the x-bit (search) for all.
So this stops listing of the files in that directory.
Then you create views for kids, pre-teens, with links to the files (or symbolic link through the master directory (problem of guessing names)) their group membership entitles them to.
So something like :
Video/<video-name>
Video-Kids/<kids-only-video-name>
Video-Teens/<kids-teens-video-name>
You have all the files in same place for your convenience, but you have un-viewable files not present.
ACL’s are supported in Linux, they just tend to be too complicated for sane ppl to administer, which has been the case in every real commercial situation I’ve seen. Multiple-group membership is powerful, efficient and possible to administer without DBMS.
The reason why using application to hide files/sub-directories in an applicaton listing, is simply the “security” is totally illusory. Any programmer (even scripts) can work round it.
So you actually need opening of directories at kernel level, to censor the entries, depending on the perms according to some mandatory mechanism, which then needs some sort of policy registry to adminster.
Just use the multi-view solution, and links, as the designers intended.
The Windows feature “Hidden Files” is also totally broken and no real security, just mount C:\ under Linux and list it. It’s a mistake to copy features that rely on Black Box obscurity rather than real benefits, it just keeps the end-users in the dark, and helps (not hinders) the blackhats.
hcvv;
The question to NFS security was answered in one of your prior thread responces.
Thanks,
John
robopensuse;
In my situation, I have a single nfs share /Network on the server that is mounted on the client at /media/network. Inside that share is the Video Folder.
If I was to go the route you suggested, Could I make it so the kids cant go into the Video folder, but thru links access files within sub folders in the Video Folder?
The second issue I run into, I am changing movies depending on the time of year. Does any one have a simple script that can create sym links on the fly after being ran depending on group?
Thanks,
John
In a NFS share I have between office and TV room, the simlinks show as empty (zero bytes) files and do not redirect to the actual file if opened from the client, even tough both directories are under the the shared directory and have the same permissions. Something like this on the server:
/home/user/shared-directory/
/home/user/shared-directory/file-directory/file.avi
/home/user/shared-directory/link-directory/link-to-file.avi
From the client, where /home/user/shared-directory/ is mounted somewhere, I can run file.avi (from file-directory) but not link-to-file.avi (from link-directory).
In the server I can run both, of course.
Is there any way to make the NFS client honor the simlink?
Apologies if it is a newbie question, didn’t notice this in the nfs/export man pages.
TIA
brunomcl;
On my file server I exported a directory I created /Network. In side that folder is a Video (/Network/Video) folder with sub folders and files. After this thread, I created a /Network/Video-kids folder on the file server and created sym-links to the files on /Network/Video/<moviename>/moviename.avi. But I am still exporting at /Network, so the clients dont know any better.
This is not the solution I am looking for, but it will do for now.
Hope this helps you out as well,
John
This curious. The exported directory, when mounted on the client, is like very other mounted partition. And symlinks within that partition are not changed at all. As long as those symlinks point to files inside the NFS mount I can not see why that should not work. In fact I have this construction running here and it functions. Inn the case the symlink points to a file on the server system that is outside the NFS export, that link exists on the client system, is not zero, but contains the name, but can not be used of course (like any symlink where you delete the file it points to).
But as you only told us something instead of giving some real information, you could give us
from the server:
The fs-type of the filesystem on the server where a (sub)directory is exported from;
ls -l /home/user/shared-directory/file-directory/file.avi /home/user/shared-directory/link-directory/link-to-file.avi
and from the client:
ls -l /somewhere/shared-directory/file-directory/file.avi /somewhere/shared-directory/link-directory/link-to-file.avi
OMG I’m stupid :). After reading that it works for you it occurred to me to check on where the simlink is pointing. The problem is that it points to the exact path on the server:
/home/user/shared-directory/file-directory/file.avi
but in the client the shared file resides in
/user/mount-point/file-directory/file.avi
.
The link won’t find anything because the directory it looks for - /home/user/shared-directory/ - doesn’t exist in the client, only in the server. If I change the mount-point path to the same as the server the symlinks work.
Now, I know there are two types of links, soft and hard (or something like that). The link I’m using is the one made by the “create link” context menu option in konqueror (server runs oS 11.1/KDE3.5) when I drag the file.
Is there a way to have a ‘relative’ link, i.e., that gets somehow translated if the mount point structure is different?
Thanks hccv and Johnfm3 for your help. It’s much appreciated.
Of course. The symlink (why simlink, it is short for symbolic link, or is that beyond my non-native knowledge of english?) in fact contains the pathname to a directory/file. And as every path to a file it can be absolute and relative.
E.g. when I am in my home directory and have a file named fff I can make a symbolic link in several ways:
ln -s fff lll
ln -s /home/henk/fff lll
ln -s ../henk/fff lll
ln -s ../../home/henk/fff lll
ln -s ./fff lll
(more ???)
In your case I would not go further back then the exported directory to be on the save side.
Two more remarks.
You stated that the ‘wrong’ links you have are zero size. That is not true. When you do an *ls -l *of them you will see that they have a size that is the same as the number of characters the link points to (fair enough, that is needed and sufficient).
You mentioned ‘hard’ link. They are something completely different. As you may know a directory contains entries with information about every file inside tht directory. These are mainly pointers. Pointer to the meta information (like the owner and the access bits) and pointer to the real diskblocks of the file. When you make somewhere in the same or another directory, a pointer to the same information, you see from that directory the same sort of things, albeith from a different place (in the directory tree) and maybe with a different name. These two are hardlinks to the same file. There is no hierarchy, both point in the same way to the same information. When you change the owner of one of the files, you will see that mirrored in the other, because they are the same. When you *rm *one, you only remove the entry in the directory. Only when the last directory entry is removed (and no process has the file open), the disk blocks are marked as free. As these are pointers to blocks on the disk, this can only be done on the same disk (partition).
Thanks, did some reading on hard x symbolic links to better understand the issue. In this case symlinks are preferable.
Indeed. One of the above should work. Konqueror’s context menu always create a full-path symlink (as it should), and I assumed that was the only way. Thanks for the clarification, very useful. As the saying goes, the devil is in the details 
Again the devil/details thing. I was referring to konqueror’s file size listing, that shows 0B for a broken link, even if it in fact uses a few dozen bytes. Or you could also see it in terms of allocated disk space, then it takes 4KB in my ext3 fs. As most things in life, it depends on how you look at it - or how precise you have to be.
Set the Master directory overall to owner/group that it should have.
If you use symlinks to directories, use relative links; ln -s …/Master/<film_dir> <film>
Safe to use file hard links at bottom level. For someone experienced, it’d be trivial to create script to automate the other directories, depending on the group in Master directory, and then have it automatically implemented.
But that requires understanding shell scripting.
The second issue I run into, I am changing movies depending on the time of year. Does any one have a simple script that can create sym links on the fly after being ran depending on group?
I don’t think it’s hard to do, just need put the movie files in the right group, and then use that info, to populate the other directories.