Ethan,

That question is really for the previous webrev (i.e., the 000 permission CR).
But ....  I can change it to root/root.  I thought that webservd/webservd was a
fine ownership since it is used by the webserver.  I did not realize that it was
also used by tftpd.  Actually, I did but didn't think about it I guess.

I can also change the ownership if you like.  I wanted to limit the exposure
hence the permission and ownership settings.  root/root and 555 is fine too.

It just means more changes.

Thanks,

John

On Sep 21, 2011, at 5:47 PM, Ethan Quach wrote:

> John,
> 
> I have another question (which again might root back to the previous fix, but 
> it's evaluation doesn't really explain much).  Why do we need to make the dir 
> owned by webservd at all?  It's readable by all others now, so I don't see 
> why we don't leave it owned by the user who is creating it (root in this 
> case).
> 
> The image dir doesn't have to same requirements as some of the other files 
> that we're making owned by webservd, so setting it's ownership seems 
> superfluous.
> 
> 
> -ethan
> (sent from my phone.)
> 
> On Sep 21, 2011, at 3:41 PM, John Fischer <[email protected]> wrote:
> 
>> All,
>> 
>> I have an updated webrev located at:
>> 
>>   
>> https://cr.opensolaris.org/action/browse/caiman/johnfisc/7093477-tftp-permissions-2
>>   
>> https://cr.opensolaris.org/action/browse/caiman/johnfisc/7093477-tftp-permissions-diff
>> 
>> The new permissions are 755 (rwxr-xr-x).
>> 
>> I have tested this in a similar manor as before.
>> 
>> Thanks,
>> 
>> John
>> 
>> On 09/21/11 03:19 PM, Seth Goldberg wrote:
>>> Hi,
>>> 
>>>    FWIW,  I think 755 is definitely adequate.  I don't see a reason to go 
>>> with 775, either.
>>> 
>>> --S
>>> 
>>> On Sep 21, 2011, at 3:11 PM, John Fischer wrote:
>>> 
>>>> Ethan,
>>>> 
>>>> 555 actually will work for both failures (this and 000 permissions issue).
>>>> We need at least RWX for the owner.  I think that we can get away with
>>>> 755.  However, I am not 100% comfortable making a permission too
>>>> tight at this point in time.
>>>> 
>>>> Do you want me to change the permissions to 755?
>>>> 
>>>> Thanks,
>>>> 
>>>> John
>>>> 
>>>> On 09/21/11 03:04 PM, Ethan Quach wrote:
>>>>> John,
>>>>> 
>>>>> This question might root back to the previous fix, but why 775?  Why 
>>>>> doesn't 755 work?
>>>>> 
>>>>> 
>>>>> -ethan
>>>>> 
>>>>> 
>>>>> On 09/21/11 14:54, John Fischer wrote:
>>>>>> All,
>>>>>> 
>>>>>> Can I get a couple of folks to look at the webrev for CR 7093477:
>>>>>> 
>>>>>>   http://monaco.us.oracle.com/detail.jsf?cr=7093477
>>>>>>   unable to boot x86 client with newly created service
>>>>>> 
>>>>>> This issue prevents x86 clients from being able to boot
>>>>>> into the install environment.  Essentially the new permission
>>>>>> changes prevent tftpd from reading the image directories.
>>>>>> The fix is simply to make the directory have 775 permissions.
>>>>>> 
>>>>>> The webrev is located at:
>>>>>> 
>>>>>>   
>>>>>> https://cr.opensolaris.org/action/browse/caiman/johnfisc/7093477-tftp-permissions
>>>>>> 
>>>>>> I have tested both the web interface via firefox (i.e., webservd
>>>>>> can read the directory) and the client can get to the image.
>>>>>> Mary has also tested that the client gets an image now.
>>>>>> I swore I tested both parts before but obviously missed it.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> John
>>>>>> _______________________________________________
>>>>>> caiman-discuss mailing list
>>>>>> [email protected]
>>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>>> _______________________________________________
>>>>> caiman-discuss mailing list
>>>>> [email protected]
>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>> _______________________________________________
>>>> caiman-discuss mailing list
>>>> [email protected]
>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>> 

_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

Reply via email to