group permission probs
 

yes, yes.. I know. this has been asked millions upon millions of times before. I did do a search for similar scenarios already, but I guess I either gave up too early or failed to see the similarities between the search results and my problem.

Back in university, my CS prof had certain files that we (being the students) were allowed to look at. As far as I understand it, this is how the permissions were set up:

Professor:
Username: neffr
Primary group: faculty
Home: /home/neffr

Me:
Username: van02018
Primary group: student
Home: /home/van02018

My friend:
Username: all02003
Primary group: student
Home: /home/all02003

Our professor had certain directories like /home/neffr/cs165/hw01/data/. Within that data directory were files we were to use with our programs. The whole idea behind allowing users who are members of group student to access the hw01 and deeper directories makes perfect sense to me... it seems so simple. So I tried to do a similar thing with my box here at home. I want my dad to be able to see my programs in /home/wheaties/programs/, assuming I added him to group cppuser (which I did, as well as myself)

I figured it would be as simple as:
chown -R wheaties.cppuser /home/wheaties/programs/
chmod -R 2750 /home/wheaties/programs/

However, when my dad tries to even cd into the programs directory he is presented with a permission denied error. I've tried every variation of the above commands that I can think of... Is there something I'm doing wrong? ...... that's a dumb question ... obviously there is if it's not working and I have to ask the more "endowed" folks around. lol

TIA

How about adding a group, call it "local", then add all the users that should have access to the files as members of that group. Now change group ownership of that dir and the files beneath to "local".
Should be about it me thinks.

yeah, that's what I was thinking too... the group I made specifically for this purpose was cppuser, which I used in my "I figured it would be as simple as:" bit.

It seems so simple, doesn't it? And yet, it's not WORKING!! [insert tourettes-caused behavior here]

If you do "id -Gn" in the "wheaties" and "dad" account, the groupname "cppuser" should show after the users' own group (if you use per user groups). Does it? Same way around for "cppuser". If you do "getent group cppuser", "wheaties" and "dad" should show. Do they?

Now I'm gonna stoop to using strace in the most lame way :-] Let your dad do his thing, and on the first error execute the same command as "strace <instercommandhere> 2>&1|grep "\-.[ ]E.*"". Post those lines.

yup, both wheaties and dad have cppuser in their group list. Group cppuser has both wheaties and dad in it's list...

The output of strace is quite cryptic... but I guess you know a thing or two about it since you told me to do it and post what happens, eh?

$ strace ls /home/wheaties/programs 2>&1|grep "\-.[ ]E.*"
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
ioctl(1, SNDCTL_TMR_TIMEBASE, 0xbffff740) = -1 EINVAL (Invalid argument)
ioctl(1, TIOCGWINSZ, 0xbffff818) = -1 EINVAL (Invalid argument)
stat64("/home/wheaties/programs", 0x805b01c) = -1 EACCES (Permission denied)

also, I thought you might be interested in this

$ strace cd /home/wheaties/programs
strace: cd: command not found

I noticed that bit about /etc/ld.so.preload not existing after I posted... I'm going to try this on my Zaurus and see what happens.

yeah, it works on my Z... must be something with my general configuration... maybe?

$ strace cd /home/wheaties/programs
strace: cd: command not found
How come? "echo $PATH" should show ":/bin" in it...

The ld.so.preload line is fine, because preload means preload libraries which can be used (debugging) but abused as well. The ioctl lines are OK as we're not interested in IO streams control, but the stat64("/home/wheaties/programs", 0x805b01c) = -1 EACCES (Permission denied) line is where we got the problem, and unfortunately it doesn't show me anything I would want to know. Sorry to have wasted your time on that one. got an idea tho actually trying this myself by now (boo, hiss)

]$ umask
027
]$ echo $SHELL
/bin/bash
]$ id -Gn | sepSpace 2
local
]$ mkdir -p /var/tmp/unspawn/local
]$ ls -ld /var/tmp/unspawn/local
drwxr-x--- unspawn unspawn /var/tmp/unspawn/local
]$ chown -R unspawn.local /var/tmp/unspawn/local
]$ ls -ld /var/tmp/unspawn/local
drwxr-x--- unspawn local /var/tmp/unspawn/local
]$ ls -ld /var/tmp/unspawn
drwxr-x--- unspawn unspawn /var/tmp/unspawn

See? So AFAIK, it's been plain parent dir perms...

that still doesn't make much sense to me... seems like parent dir permissions shouldn't really matter, especially since I've seen this done (whole idea behind doing it).

I didn't have each user set up with their own group, but I have added these groups for each user now. I can't see how it will affect me yet because I made the foolish [in]decision to compile gcc on a p3 550Mhz today. I say indecision because it was a dependency that just decided it wanted updating :( lol... it'll be a while before I'm able to log out to make the appropriate changes to my account.

I really do appreciate all of your help. but is there any other explanation that you can think of for this behavior? I mean it works just fine on my Zaurus, and I'm pretty sure that if I tried it on a different distro it would work as well... is there any sort of config file you know of that I may need to modify?

that still doesn't make much sense to me... seems like parent dir permissions shouldn't really matter
May be, may be not, but if dir /home/wheaties has 0700 perms then cppuser group ownership wouldnt matter, or if it has 0750 perms and *not* cppuser group ownership then it does.
Could you just "ls -ld" /home/wheaties and programs?

is there any other explanation that you can think of for this behavior
None I know of: strace doesnt reveal any. I doubt there'll be other pitfalls.

root # ls -ld /home/wheaties/
drwxr-x--- 33 wheaties wheaties 1784 Aug 19 20:41 /home/wheaties/
root # ls -ld /home/wheaties/programs/
drwxr-x--- 7 wheaties cppuser 200 Aug 16 14:20 /home/wheaties/programs/

oh yeah, /bin was in my path (from your post earlier, pertaining to why "cd" didn't work)

if dir /home/wheaties has 0700 perms then cppuser group ownership wouldnt matter, or if it has 0750 perms and *not* cppuser group ownership then it does.

drwxr-x--- wheaties wheaties /home/wheaties/

Change group ownership of /home/wheaties to cppuser (good, if only contains trusted users and no writing is allowed), or make it world executable (bad).

yeah, that might be what I end up doing... but it still (yes, I am beginning to annoy myself with this "obsession" as it seems to have become) does not accomplish the task that I set out to do.

I am trying to get this down in case I am in a similar situation as I was at school. Only I would be in the teacher's shoes, kinda. I want to have my own home directory, only accessible by myself. Then I want to make certain subdirectories that only members of certain groups (which I define, of course) can use.

Does that make any sense at all? I guess it could be rather confrusing if you weren't there to actually see what I mean.

yeah, that might be what I end up doing.
No, thats what you will be doing to actually make it work.

Does that make any sense at all?
Yes it makes sense and IMHO, no, it won't work because of the necessity for appropriate parent dir group permissions. If group cppuser doesn't have read permissions on the parent dir, then it can't ls the dirs' contents. Same if group cppuser doesn't have execute permissions on the parent dir, then it can't cd into the dir.
Of course if you only give the group execute permissions, and only reference applications in /home/wh.*/prog.* by their full path then (provided the app allows has the right perms set) it should work. If you won't allow for shared dirs/apps that way (which I agree is a bad thing), then setting up the apps in /usr/local/bin is the only middle ground I guess.