mvn -Pnative -Dworker-launcher.conf.dir=${EXEC_CONF_DIR}

Will build it with whatever directory you set.  It defaults to /etc/storm
but that can be modified in storm-core/pom.xml. If /etc would be better in
general we can file a JIRA for that change.

I took the core of the code from Hadoop so there is definitely room for
improvement in better integrating it with storm.  I think it should be OK
to let the location of the config be set by storm.yaml.  There was
discussion about a similar feature in Hadoop, the biggest issue here is
that if the path is not hardcoded an attacher could pick any root owned
file to use.  To exploit this a compatible file with more lax or incorrect
group settings would have to exist on the box and be owned by root and not
be group or world writable.  This seems fairly secure, but in the case of
NFS you could compromise one box setup the config on an NFS server as root
and then use that to compromise other systems.  This is why NFS mounting
has options for disabling setuid/setgid support on files.

I know it is a bit far fetched, but so much of security ends up being that
way.

- Bobby

On 7/15/14, 10:39 AM, "Harsha" <[email protected]> wrote:

>Raghav,
>       EXEC_CONF_DIR is a issue as we have to manually pass it while
>       building.
>I think it should be part of storm.yaml and passed to worker-launcher as
>an argument.
>-Harsha
>
>On Mon, Jul 14, 2014, at 11:20 AM, Raghavendra Nandagopal wrote:
>> Hi Bobby,
>>   I have couple of questions on Storm security configurations.
>> 
>> 1) For providing the path to the file "worker-launcher.cfg", I modified
>> the
>> file worker-launcher.c and added the below line.
>> 
>> EXEC_CONF_DIR = /etc
>> 
>> Do we need to do this manually for setting storm security or is it done
>> through any configuration parameter?
>> 
>> 2) We have a set of users who will be authenticated through Kerberos and
>> obtain the TGT.  Although the user obtained the TGT, the user should not
>> be
>> authorized to submit/manage the topologies within the storm cluster.  Do
>> we
>> have any kind of ACLs that can be set in Nimbus for a specific
>> users/groups?
>> 
>> Thanks,
>> 
>> Raghavendra Nandagopal
>> 
>> 
>> 
>> On Wed, Jul 9, 2014 at 8:42 AM, Bobby Evans
>><[email protected]>
>> wrote:
>> 
>> > Great to hear, if you do have any more issue please feel free to
>>reach out
>> > and I will do my best to answer them.
>> >
>> > - Bobby
>> >
>> > On 7/9/14, 6:03 AM, "Raghavendra Nandagopal" <[email protected]>
>> > wrote:
>> >
>> > >Please ignore the above issue.  I have resolved the issues with the
>>storm
>> > >security setup.  It is working fine.
>> > >
>> > >Thanks,
>> > >Raghav
>> > >
>> > >
>> > >On Tue, Jul 8, 2014 at 8:53 PM, Raghavendra Nandagopal <
>> > >[email protected]> wrote:
>> > >
>> > >> Hi,
>> > >>    I am trying to setup storm security branch code.  All the
>>services
>> > >> (zookeeper, nimbus, supervisor, ui) are getting authenticated from
>> > >> Kerberos.  I did get into some issues with "worker-launcher"
>>executable
>> > >> with permissions and set the binary permission to *4470.  *Once the
>> > >> permissions where set it didn't add any issues with the
>>worker-launcher
>> > >> permissions.
>> > >>
>> > >> I am facing a new problem while submitting a topology, below is the
>> > >> exception that is occurring in nimbus.  The nimbus is getting
>>halted.
>> > >>The
>> > >> exception is thrown by zookeeper but couldn't figure out any trace
>>of
>> > >>it.
>> > >>  Please let me know if you have come across the problem and any
>> > >> configurations that needs to be taken care in Storm security
>>branch.
>> > >>
>> > >> *java.lang.RuntimeException:
>> > >> org.apache.zookeeper.KeeperException$NoAuthException:
>>KeeperErrorCode =
>> > >> NoAuth for
>> > >>
>> > 
>>>>/workerbeats/exclamation-topology-1-1404876382/db219ca4-da85-4c68-87c0-
>>>>84
>> > >>734c9e89da-6703*
>> > >>
>> > >> Thanks,
>> > >>
>> > >> Raghav
>> > >>
>> >
>> >

Reply via email to