On Thu, 22 Dec 2011 14:33:47 -0500 Tanstaafl <tansta...@libertytrek.org> wrote:
> Thanks for the explanation Alan... have to do some reading/studying > on this. > > Any good pointers for best practices for this kind of thing? "Best practice" - the two most useless words in all of IT. By definition best practice is always optimized for someone else (or for nothing), never for you. Yes, there are guidelines about security that are very helpful, but step 1 is always to know exactly what YOU are trying to accomplish and what is going to work best for YOU. Your opinion in this is everything, mine is almost irrelevant. Best advice I can give is to read up on the various technologies mentioned in this thread so that you have a good grasp of what they achieve (never mind the detail, think big picture). Usually, what you should do next then becomes quite obvious. > > Thanks again... > > On 2011-12-22 2:21 PM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > > On Thu, 22 Dec 2011 13:53:43 -0500 > > Tanstaafl<tansta...@libertytrek.org> wrote: > > > >> On 2011-12-22 1:00 PM, Nikos Chantziaras<rea...@arcor.de> wrote: > >>> On 12/22/2011 05:44 PM, Tanstaafl wrote: > >>>> On 2011-12-20 12:19 PM, Nikos Chantziaras<rea...@arcor.de> > >>>> wrote: > >>>>> If you allow someone to edit root owned files, you're > >>>>> practically giving him root access. > >>>> > >>>> Well, yeah, but only on those defined files... > >>> > >>> root access is global. You can't limit it. root is root, the all > >>> powerful Unix being. Period :-) > >> > >> Ummm... then what is the purpose of sudo?? > > > > The purpose of sudo is to provide *fine-grained* control of elevated > > privilege to users and groups. Few people seem to realize just how > > finely this can be controlled, most assume that sudo lets you become > > root and that's it. > > > > As with all things fine-grained, it can get very complex very > > quick. If you want to allow 5 commands to operate on 5 files, you > > have to make 25 allow statements (unless you can use some funky > > wildcard syntax). > > > > > >> > >> If I add the following line to sudoers: > >> > >> %sudoroot > >> ALL=(root)NOPASSWD:/bin/chmod /var/www/localhost/htdocs/* > >> > >> Are you saying that this does NOT limit anyone in the sudoroot > >> group to *only* be able to run the chmod command, and only on > >> files located in /var/www/localhost/htdocs? > > > > Not quite, take out the word "only". When you say only, you exclude > > everything else and that is not true - you might have a second set > > of permissions somewhere else. The line you quoted does exactly what > > you said without the word "only" - it allows the action. Different > > commands and different files are outside the scope of that config > > line > > > >> > >>> Then you put the files in a special group and make them g+w, and > >>> add the affected users to that group. Then they will able to write > >>> to those files. If you want to give them write access to a whole > >>> directory, you put the directory in the group and make it g+w. > >>> This is how it's traditionally been done in Unix for ages, and > >>> it's extremely easy to set up. > >> > >> Yeah, I think I got a little tunnel vision trying to do this with > >> sudo. > > > > Permissions and right of access is hard. Few people know how to do > > it right, and you can't consider just sudo in isolation. > > > > sudo is one command in a whole system and you have to take that into > > account too. The method you use will depend more on everything else > > that machine can do than just on what sudo you can do. > > > > If you need to allow just one single user to access just one single > > directory, you are better off with using Posix ACLS (NOT regular > > owner, group and perms - that almost never works out right for www > > data) > > > > If you have many different users needing all sorts of different > > access to things, you might even consider SE-Linux. Just be > > prepared for huge amounts of customizing. But if it really is what > > you need, SE Linux is worth the sweat. > > > > > > -- Alan McKinnnon alan.mckin...@gmail.com
