Re: [Spacewalk-devel] [PATCH] Kickstart profiles error handling
On 11/07/2012 04:50 PM, Tomas Lestach wrote:
On Tuesday 06 of November 2012 12:30:09 Johannes Renner wrote:
Hello,
this is a proposed extension to commit 1ea830a in master:
Validation of a kickstart profile is currently done by downloading it from
the locally running cobbler. In case of validation problems there is a
DownloadException thrown that we can catch and work with.
Therefore in case of an error, it makes IMO not very much sense to point to
the 'Kickstart File' tab, where the downloaded file contents should
actually be shown to the user. The cobbler returns a status 500 in this
case, so what we see on this page is the source code of the apache error
page. Further, the download link is of course not working.
Right. I see your point.
The attached patch contains the following proposed changes to the code:
1. Change the error message text to point to the file contents on the
'Details' tab 2. Hide the content on the 'Kickstart File' tab in case the
download failed
The problem with your patch is that you don't propagate any helpful (error)
message to the user. So if he uploads a kickstart file, that is considered
wrong for some reason, I - as an user - would like to know what was the
problem with the kickstart file.
I know that the 500 page we display now isn't helpfull as well.
I'll try check the code and see if I find something out.
Yes, my cobbler log contains some helpful info, but how to bring this excerpt to
the UI if we are only reacting to a download that failed? I didn't dig deep into
it, I just wanted to hide the html source of the 500 error page. But I agree it
would be much better to present such details to the user.
Excerpt from cobbler.log:
...
Here is the corresponding Cheetah code.
** I had to guess the line column numbers, so they are probably incorrect:
Line 47, column 8
Line|Cheetah Code
|-
44 |
45 |mkdir -p /tmp/rhn
46 |
47 |drives=$(list-harddrives | awk '{print $1}')
^
48 |for disk in $drives; do
49 |DISKS=$DISKS $(fdisk -l /dev/$disk | grep -v swap\|LVM\|Extended |
awk '/^\/dev/{print
$1}')
50 |done
...
BTW: This error occurred with a kickstart file that was generated using the
wizard
and pasted into the new profile form afterwards. The cheetah seems to complain
about
the $ signs in the bash code and wants me to escape them. Actually I would
expect
this to work, or not? Not so sure how the cheetah will distinguish between bash
$
signs and kickstart variables?
Thanks,
Johannes
--
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] List of installable packages: API vs. Web UI
On 11/05/2012 12:03 PM, Tomas Lestach wrote: ... If there's a bug in the API call, we of course fix it. But we try to keep the current API interface as is. Spacewalk users have their scripts using our API calls and we do not want to break the scripts by renaming/deleting existing API calls. (Introducing of new sensefull APIs is always good. :) So, it is important that the API behaves according to its name. It the name and behavior do not match, we fix the behavior according to the name and can introduce a new API in case the behavior of the original API was helpfull. However, internal naming has lower priority, because the users do not come into contact with it, so it cannot be confusing for them. (But we of course try to keep the naming sensefull as well.) Ok, I might come up with a patch these days, fixing the existing API call so it behaves like its name is suggesting + maybe add a new call to provide the previous behavior in addition to that. Thanks for the explanations, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Rationale for rhncfg-actions should not log the diff of files that are not readable by all
Can anyone explain the rationale behind commit 7a18b250b07ff4ed0c34fa48e69029c114ec3ab1? I do not have access to the BZ that it references. I don't see the security implications of generating a diff for a non-world-readable file. Unauthorized users can't read the file on the system and you need to have access to the system in Spacewalk to view the output. Is there another scenario that makes returning the diff insecure? /aron ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Rationale for rhncfg-actions should not log the diff of files that are not readable by all
On 11/08/2012 10:34 AM, Parsons, Aron wrote: Can anyone explain the rationale behind commit 7a18b250b07ff4ed0c34fa48e69029c114ec3ab1? I do not have access to the BZ that it references. I don't see the security implications of generating a diff for a non-world-readable file. Unauthorized users can't read the file on the system This did not used to be true. We were generating diffs of every file and placing them in a readable-by-anyone log file. In bug 824707 we fix this problem by 1) Not diffing files that are not readable by all in 7a18b250b07ff4ed0c34fa48e69029c114ec3ab1 and then we also 2) Made the log file only readable by root in 0cb9f801bfc073cd68111868014219407b73f9f9 Both are probably not necessary, but the feeling at the time was better safe than sorry. -Stephen and you need to have access to the system in Spacewalk to view the output. Is there another scenario that makes returning the diff insecure? /aron ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Rationale for rhncfg-actions should not log the diff of files that are not readable by all
So many of the files that I deploy in my environments are not world-readable, as were lots of other environments I worked with in the past. I see this change as a reduction in functionality, as now instead of viewing the diffs in Spacewalk, I need to log into each system before determining the course of action. More importantly, when manually running 'rhncfg-client diff', I fully expect to see a diff, not an error message telling me to redeploy. Thoughts on reverting 7a18b250b07ff4ed0c34fa48e69029c114ec3ab1 since the security issue is addressed by protecting the log file? /aron -Original Message- From: Stephen Herr [mailto:sh...@redhat.com] Sent: Thursday, November 08, 2012 1:03 PM To: spacewalk-devel@redhat.com Cc: Parsons, Aron Subject: Re: [Spacewalk-devel] Rationale for rhncfg-actions should not log the diff of files that are not readable by all On 11/08/2012 10:34 AM, Parsons, Aron wrote: Can anyone explain the rationale behind commit 7a18b250b07ff4ed0c34fa48e69029c114ec3ab1? I do not have access to the BZ that it references. I don't see the security implications of generating a diff for a non-world-readable file. Unauthorized users can't read the file on the system This did not used to be true. We were generating diffs of every file and placing them in a readable-by-anyone log file. In bug 824707 we fix this problem by 1) Not diffing files that are not readable by all in 7a18b250b07ff4ed0c34fa48e69029c114ec3ab1 and then we also 2) Made the log file only readable by root in 0cb9f801bfc073cd68111868014219407b73f9f9 Both are probably not necessary, but the feeling at the time was better safe than sorry. -Stephen and you need to have access to the system in Spacewalk to view the output. Is there another scenario that makes returning the diff insecure? /aron ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
