1 |
Thanks for the explanation Alan... have to do some reading/studying on this. |
2 |
|
3 |
Any good pointers for best practices for this kind of thing? |
4 |
|
5 |
Thanks again... |
6 |
|
7 |
On 2011-12-22 2:21 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
8 |
> On Thu, 22 Dec 2011 13:53:43 -0500 |
9 |
> Tanstaafl<tanstaafl@×××××××××××.org> wrote: |
10 |
> |
11 |
>> On 2011-12-22 1:00 PM, Nikos Chantziaras<realnc@×××××.de> wrote: |
12 |
>>> On 12/22/2011 05:44 PM, Tanstaafl wrote: |
13 |
>>>> On 2011-12-20 12:19 PM, Nikos Chantziaras<realnc@×××××.de> wrote: |
14 |
>>>>> If you allow someone to edit root owned files, you're practically |
15 |
>>>>> giving him root access. |
16 |
>>>> |
17 |
>>>> Well, yeah, but only on those defined files... |
18 |
>>> |
19 |
>>> root access is global. You can't limit it. root is root, the all |
20 |
>>> powerful Unix being. Period :-) |
21 |
>> |
22 |
>> Ummm... then what is the purpose of sudo?? |
23 |
> |
24 |
> The purpose of sudo is to provide *fine-grained* control of elevated |
25 |
> privilege to users and groups. Few people seem to realize just how |
26 |
> finely this can be controlled, most assume that sudo lets you become |
27 |
> root and that's it. |
28 |
> |
29 |
> As with all things fine-grained, it can get very complex very quick. If |
30 |
> you want to allow 5 commands to operate on 5 files, you have to make 25 |
31 |
> allow statements (unless you can use some funky wildcard syntax). |
32 |
> |
33 |
> |
34 |
>> |
35 |
>> If I add the following line to sudoers: |
36 |
>> |
37 |
>> %sudoroot |
38 |
>> ALL=(root)NOPASSWD:/bin/chmod /var/www/localhost/htdocs/* |
39 |
>> |
40 |
>> Are you saying that this does NOT limit anyone in the sudoroot group |
41 |
>> to *only* be able to run the chmod command, and only on files located |
42 |
>> in /var/www/localhost/htdocs? |
43 |
> |
44 |
> Not quite, take out the word "only". When you say only, you exclude |
45 |
> everything else and that is not true - you might have a second set of |
46 |
> permissions somewhere else. The line you quoted does exactly what |
47 |
> you said without the word "only" - it allows the action. Different |
48 |
> commands and different files are outside the scope of that config line |
49 |
> |
50 |
>> |
51 |
>>> Then you put the files in a special group and make them g+w, and |
52 |
>>> add the affected users to that group. Then they will able to write |
53 |
>>> to those files. If you want to give them write access to a whole |
54 |
>>> directory, you put the directory in the group and make it g+w. This |
55 |
>>> is how it's traditionally been done in Unix for ages, and it's |
56 |
>>> extremely easy to set up. |
57 |
>> |
58 |
>> Yeah, I think I got a little tunnel vision trying to do this with |
59 |
>> sudo. |
60 |
> |
61 |
> Permissions and right of access is hard. Few people know how to do it |
62 |
> right, and you can't consider just sudo in isolation. |
63 |
> |
64 |
> sudo is one command in a whole system and you have to take that into |
65 |
> account too. The method you use will depend more on everything else |
66 |
> that machine can do than just on what sudo you can do. |
67 |
> |
68 |
> If you need to allow just one single user to access just one single |
69 |
> directory, you are better off with using Posix ACLS (NOT regular |
70 |
> owner, group and perms - that almost never works out right for www data) |
71 |
> |
72 |
> If you have many different users needing all sorts of different access |
73 |
> to things, you might even consider SE-Linux. Just be prepared for huge |
74 |
> amounts of customizing. But if it really is what you need, SE Linux is |
75 |
> worth the sweat. |
76 |
> |
77 |
> |