Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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:
Primary group: student
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
Last edited by wheaties_box; 08-16-2003 at 09:53 PM.
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.
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.
$ 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)
]$ echo $SHELL
]$ id -Gn | sepSpace 2
]$ 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?
Last edited by wheaties_box; 08-19-2003 at 01:13 PM.
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.
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.
Last edited by wheaties_box; 08-19-2003 at 04:11 PM.
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.