The latest version LGTM.
-Drew
On 9/21/11 10:06 PM, John Fischer wrote:
Ethan, Seth and Drew,
Please review the following webrev for this issue:
https://cr.opensolaris.org/action/browse/caiman/johnfisc/7093477-tftp-permissions-3
https://cr.opensolaris.org/action/browse/caiman/johnfisc/7093477-tftp-permissions-diff2
This removes the ownership changes but retains the permission
changes as Ethan requested.
Thanks,
John
On 09/21/11 07:53 PM, Ethan Quach wrote:
Hi John,
On 09/21/11 18:37, John Fischer wrote:
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 issue I have with changing its ownership is that it really seem
non-standard . As a user, when I want to serve something from a
webserver, I don't change my files' ownership, I just make sure its
accessible by the webserver. Unless you or I or anyone else can
think of a reason why the image dir *needs* to be owned by webservd,
I don't think we should set it that way.
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.
More changes wrt the code for this bufix but, really, less compared
to what is there for 173. IMO I think changing it back is less risky.
May I suggest that rather than explicitly setting ownership to root,
just not touch ownership at all. Just fix up the perms.
thanks,
-ethan
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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
