From mboxrd@z Thu Jan  1 00:00:00 1970
From: Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH] libxl: prevent xl from running if xend	is
 running.
Date: Tue, 24 Apr 2012 18:07:44 +0100
Message-ID: <4F96DDE0.3020708@citrix.com>
References: <1335193862-37069-1-git-send-email-roger.pau@citrix.com>
	<20374.42987.732159.638716@mariner.uk.xensource.com>
	<1335274224.4347.138.camel@zakaz.uk.xensource.com>
	<20374.43998.471725.415493@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20374.43998.471725.415493@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

Ian Jackson escribi=F3:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from runn=
ing if xend	is running."):
>> On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
>>> Can we somehow limit this to commands that actually change things ?
>>> Having xl as a diagnostic tool even for xend-based systems is useful.
>> Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).
>
> Yes, something like that.

Do you mean to add a new "-f" option to each command that performs =

modifications, or modifying the cmd_spec struct to add something like =

"int modifies", and check that before trying to execute the command?

>
>>>> +        if (!access(locks[i], F_OK)&&  !force_execution) {
>>>> +            fprintf(stderr, "xend is running, which prevents xl from =
working "
>>>> +                            "correctly. If you still want to force th=
e "
>>>> +                            "execution of xl please use the -f option=
\n");
>>>> +            exit(2);
>>>> +        }
>>> If access fails with an unexpected error code (EACCES? EIO?) this will
>>> blunder on.
>> It'll fail whether the error code is expected or not, won't it?
>
> I think if access fails with EIO, it will return -1, and the if
> condition will not be satisfied (!-1 =3D 0), so the fprintf and exit
> will not be taken.
>
> Ian.