DSpace Security

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

DSpace Security

Hilton Gibson-2
Hi All

I have come across an instance of DSpace where the Tomcat6 server has been configured to run as the "root" user. It has been a rule to never run a critical production service as the "root" user on a Unix/Linux system.

My question is;
What security guidelines do the DSpace community have in this regard taking into account the many reports of Java insecurity on the web lately? 
I do not get a good feeling seeing a Java webapp running as the "root" user. It is kind of like walking across a minefield blindfolded, you know something bad is going to happen but not when.

Cheers

hg

--
Hilton Gibson
Linux Systems Administrator
JS Gericke Library
Room 1025C
Stellenbosch University
Private Bag X5036
Stellenbosch
7599
South Africa

Tel: +27 21 808 4100 | Cell: +27 84 646 4758

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
DSpace-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Reply | Threaded
Open this post in threaded view
|

Re: DSpace Security

helix84
Hi Hilton,

while I can see why this alarms you and it's generally a good policy
that I myself practice, it often doesn't matter as much as you'd
think.

Assuming the common case that a single instance of DSpace is the only
application that runs on the server, the cases of compromising the
tomcat account and the root account are equally disrupting - the
attacker gains access to data that is potentially confidential and
assumes control over the application. Whether he has control over the
machine itself is not so important - the major harm has already been
done.

Of course, a whole different case is a multi-user or multi-application
setup, including the case where you run both Tomcat and Apache on the
same machine. In this case you should use separate accounts for each
service because they are two separate attack surfaces.

You can easily find a million articles about why you shouldn't use the
root account unless it's necessary, so let me give you just one that
discusses the opposite view:
https://systemoverlord.com/2010/07/30/why-the-risk-of-running-as-root-is-overblown

Don't think that I'm opposing the general rule. It just sometimes
helps to stop and think why the general rule exists and what it
doesn't cover. No single security measure is a snake oil.

The problem with the root account is that it's not at all granular -
you either have all the privileges or none of them. That's why more
granular approaches have been worked on since the dawn of time, from
capabilities to SELinux and AppArmor.

Regards,
~~helix84

Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
DSpace-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Reply | Threaded
Open this post in threaded view
|

Re: DSpace Security

Hilton Gibson-2
Hi Helix

I believe any radical deviation from generally accepted best practice has then to be approved and responsibility for any breach handed to management.
It is up to management to manage risk, not me.
If they are happy with a greater likelihood of a security breach, then fine.

But how are we as a community to deal with it?
What best practices for system administration do we endorse?
Are we concerned about safety?

Regards

hg



On 4 June 2013 12:27, helix84 <[hidden email]> wrote:
Hi Hilton,

while I can see why this alarms you and it's generally a good policy
that I myself practice, it often doesn't matter as much as you'd
think.

Assuming the common case that a single instance of DSpace is the only
application that runs on the server, the cases of compromising the
tomcat account and the root account are equally disrupting - the
attacker gains access to data that is potentially confidential and
assumes control over the application. Whether he has control over the
machine itself is not so important - the major harm has already been
done.

Of course, a whole different case is a multi-user or multi-application
setup, including the case where you run both Tomcat and Apache on the
same machine. In this case you should use separate accounts for each
service because they are two separate attack surfaces.

You can easily find a million articles about why you shouldn't use the
root account unless it's necessary, so let me give you just one that
discusses the opposite view:
https://systemoverlord.com/2010/07/30/why-the-risk-of-running-as-root-is-overblown

Don't think that I'm opposing the general rule. It just sometimes
helps to stop and think why the general rule exists and what it
doesn't cover. No single security measure is a snake oil.

The problem with the root account is that it's not at all granular -
you either have all the privileges or none of them. That's why more
granular approaches have been worked on since the dawn of time, from
capabilities to SELinux and AppArmor.

Regards,
~~helix84

Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette



--
Hilton Gibson
Linux Systems Administrator
JS Gericke Library
Room 1025C
Stellenbosch University
Private Bag X5036
Stellenbosch
7599
South Africa

Tel: +27 21 808 4100 | Cell: +27 84 646 4758

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
DSpace-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Reply | Threaded
Open this post in threaded view
|

Re: DSpace Security

helix84
OK, I didn't mean to start a discussion, just wanted to give you a
point to think about, so let me just repeat the single point I made:

In the particular common case I described, there is no difference in
risk (neither its likelihood nor its impact) between compromising the
tomcat account and the root account.


Regards,
~~helix84

Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
DSpace-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Reply | Threaded
Open this post in threaded view
|

Re: DSpace Security

Mark H. Wood
On Tue, Jun 04, 2013 at 12:43:08PM +0200, helix84 wrote:
> OK, I didn't mean to start a discussion, just wanted to give you a
> point to think about, so let me just repeat the single point I made:
>
> In the particular common case I described, there is no difference in
> risk (neither its likelihood nor its impact) between compromising the
> tomcat account and the root account.

I think I disagree.  root can do anything, while service accounts are
usually carefully limited, and can't create new accounts, replace
system software, etc.  Compromise Tomcat and you've compromised
Tomcat; compromise root and you've taken over the machine, and can
take arbitrary actions within the security perimeter.

In the DSpace context, would it be fair to say that, while developers
take reasonable care, DSpace is not tested to run as root and should
not be so used?

--
Mark H. Wood, Lead System Programmer   [hidden email]
Machines should not be friendly.  Machines should be obedient.

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
DSpace-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DSpace Security

Tim Donohue
Administrator


On 6/4/2013 10:30 AM, Mark H. Wood wrote:
> In the DSpace context, would it be fair to say that, while developers
> take reasonable care, DSpace is not tested to run as root and should
> not be so used?

I think that's correct.

Our DSpace Installation documentation specifically recommends that
DSpace be installed under its own "service account" (a user named
'dspace'). We don't explicitly warn against using 'root'. (To be honest,
it's really up to you and your local policies what you want to do. I,
personally, never run DSpace as 'root'. I always create a service
account and run DSpace & Tomcat as that user.)

However, if you follow our DSpace instruction guidelines, the very first
step is to create a 'dspace' service user (and to run Tomcat as that
user).  See Step #1 here:

https://wiki.duraspace.org/display/DSDOC4x/Installation#Installation-InstallationInstructions

- Tim

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
DSpace-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Reply | Threaded
Open this post in threaded view
|

Re: DSpace Security

Hilton Gibson-2
Hi Tim

When creating the "dspace" user and then assigning this user the Tomcat6 account, how do we deal with file permissions needed by Tomcat6 for the following system files;
dspace@ir1:~$ dpkg -L tomcat6
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/tomcat6
/usr/share/doc/tomcat6/changelog.Debian.gz
/usr/share/doc/tomcat6/copyright
/usr/share/tomcat6
/usr/share/tomcat6/webapps
/usr/share/tomcat6/webapps/default_root
/usr/share/tomcat6/webapps/default_root/index.html
/usr/share/tomcat6/webapps/default_root/META-INF
/usr/share/tomcat6/webapps/default_root/META-INF/context.xml
/var
/var/cache
/var/cache/tomcat6
/var/log
/var/log/tomcat6
/var/lib
/var/lib/tomcat6
/var/lib/tomcat6/common
/var/lib/tomcat6/common/classes
/var/lib/tomcat6/server
/var/lib/tomcat6/server/classes
/var/lib/tomcat6/webapps
/var/lib/tomcat6/shared
/var/lib/tomcat6/shared/classes
/etc
/etc/init.d
/etc/init.d/tomcat6
/etc/tomcat6
/etc/tomcat6/context.xml
/etc/tomcat6/web.xml
/etc/tomcat6/logging.properties
/etc/tomcat6/policy.d
/etc/tomcat6/policy.d/02debian.policy
/etc/tomcat6/policy.d/50local.policy
/etc/tomcat6/policy.d/03catalina.policy
/etc/tomcat6/policy.d/01system.policy
/etc/tomcat6/policy.d/04webapps.policy
/etc/tomcat6/catalina.properties
/etc/tomcat6/tomcat-users.xml
/etc/tomcat6/Catalina
/etc/tomcat6/Catalina/localhost
/etc/tomcat6/server.xml
/etc/cron.daily
/etc/cron.daily/tomcat6
/etc/default
/etc/default/tomcat6
/usr/share/doc/tomcat6/README.Debian.gz
/var/lib/tomcat6/conf
/var/lib/tomcat6/work
/var/lib/tomcat6/logs

Regards

Hilton



On 4 June 2013 17:38, Tim Donohue <[hidden email]> wrote:


On 6/4/2013 10:30 AM, Mark H. Wood wrote:
> In the DSpace context, would it be fair to say that, while developers
> take reasonable care, DSpace is not tested to run as root and should
> not be so used?

I think that's correct.

Our DSpace Installation documentation specifically recommends that
DSpace be installed under its own "service account" (a user named
'dspace'). We don't explicitly warn against using 'root'. (To be honest,
it's really up to you and your local policies what you want to do. I,
personally, never run DSpace as 'root'. I always create a service
account and run DSpace & Tomcat as that user.)

However, if you follow our DSpace instruction guidelines, the very first
step is to create a 'dspace' service user (and to run Tomcat as that
user).  See Step #1 here:

https://wiki.duraspace.org/display/DSDOC4x/Installation#Installation-InstallationInstructions

- Tim

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
DSpace-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette



--
Hilton Gibson
Linux Systems Administrator
JS Gericke Library
Room 1025C
Stellenbosch University
Private Bag X5036
Stellenbosch
7599
South Africa

Tel: +27 21 808 4100 | Cell: +27 84 646 4758

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
DSpace-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Reply | Threaded
Open this post in threaded view
|

Re: DSpace Security

Mark H. Wood
On Wed, Jun 05, 2013 at 09:59:04AM +0200, Hilton Gibson wrote:
> Hi Tim

I'm not Tim, but here's my 2¢ worth anyway.

> When creating the "dspace" user and then assigning this user the Tomcat6
> account, how do we deal with file permissions needed by Tomcat6 for the
> following system files;
> *dspace@ir1:~$ dpkg -L tomcat6*
> */.*
> */usr*
> */usr/share*
> */usr/share/doc*
> */usr/share/doc/tomcat6*
> */usr/share/doc/tomcat6/changelog.Debian.gz*
> */usr/share/doc/tomcat6/copyright*
> */usr/share/tomcat6*
> */usr/share/tomcat6/webapps*
> */usr/share/tomcat6/webapps/default_root*
> */usr/share/tomcat6/webapps/default_root/index.html*
> */usr/share/tomcat6/webapps/default_root/META-INF*
> */usr/share/tomcat6/webapps/default_root/META-INF/context.xml*
> */var*
> */var/cache*
> */var/cache/tomcat6*
> */var/log*
> */var/log/tomcat6*
> */var/lib*
> */var/lib/tomcat6*
> */var/lib/tomcat6/common*
> */var/lib/tomcat6/common/classes*
> */var/lib/tomcat6/server*
> */var/lib/tomcat6/server/classes*
> */var/lib/tomcat6/webapps*
> */var/lib/tomcat6/shared*
> */var/lib/tomcat6/shared/classes*
> */etc*
> */etc/init.d*
> */etc/init.d/tomcat6*
> */etc/tomcat6*
> */etc/tomcat6/context.xml*
> */etc/tomcat6/web.xml*
> */etc/tomcat6/logging.properties*
> */etc/tomcat6/policy.d*
> */etc/tomcat6/policy.d/02debian.policy*
> */etc/tomcat6/policy.d/50local.policy*
> */etc/tomcat6/policy.d/03catalina.policy*
> */etc/tomcat6/policy.d/01system.policy*
> */etc/tomcat6/policy.d/04webapps.policy*
> */etc/tomcat6/catalina.properties*
> */etc/tomcat6/tomcat-users.xml*
> */etc/tomcat6/Catalina*
> */etc/tomcat6/Catalina/localhost*
> */etc/tomcat6/server.xml*
> */etc/cron.daily*
> */etc/cron.daily/tomcat6*
> */etc/default*
> */etc/default/tomcat6*
> */usr/share/doc/tomcat6/README.Debian.gz*
> */var/lib/tomcat6/conf*
> */var/lib/tomcat6/work*
> */var/lib/tomcat6/logs*
If your servlet container (e.g. Tomcat) already has an account, that
account should own the DSpace files.  You only need to create a user
"dspace" if you are installing Tomcat from source and can't decide
what to name its account.  (In that case I would name it "tomcat" and
let the DSpace files be owned by "tomcat".  There's nothing
significant about a user named "dspace".)

Anyway, whatever owns Tomcat should own DSpace and vice versa.  If
your distribution creates an account when installing Tomcat, use that
for DSpace as well.  Trying to make it work with two separate accounts
is painful and unnecessary, as is trying to rejigger Tomcat to run as
a different account than what your package manager used to install it.

The DSpace documentation seems to assume that you are installing all
prerequisites by hand and have no other use for Tomcat.  I've schemed
to remold that section but haven't yet found an acceptable way to get
rid of this confusing "dspace" user.  I continue to watch it from the
shadows, devising strategems....

--
Mark H. Wood, Lead System Programmer   [hidden email]
Machines should not be friendly.  Machines should be obedient.

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
DSpace-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DSpace Security

Tim Donohue
Administrator
I agree with what Mark Wood has stated.

Here's a bit more info to describe some common options for setting up
Tomcat + DSpace.

[Option#1:] If you are installing Tomcat manually (NOT via a Linux
package manager), then you may want to install it such that it is owned
by a user named "dspace" (or similar). The current DSpace Documentation
essentially assumes you are installing Tomcat manually (by going to
http://tomcat.apache.org and downloading the zipped up binaries).

[Option#2:] If you are using the Tomcat package provided by your Linux
OS package manager, then you may want to just run DSpace as the "tomcat"
user (rather than creating a new "dspace" user). This is perfectly
acceptable. As Mark notes, the key is that you want Tomcat & DSpace to
be owned by the same user (but it doesn't matter who that user is).

[Option#3] (what I tend to do): If you are on Ubuntu, you could use the
"tomcat*-user" package to actually install Tomcat under whatever user
account you want. For example:
    # Install Tomcat7 & its "user" tools

    $ sudo apt-get install tomcat7 tomcat7-user

    # Create a new Tomcat instance in /home/dspace/tomcat (or where ever
you want), using the "tomcat7-create-instance" script provided by
'tomcat7-user' package

    $ sudo tomcat7-create-instance /home/dspace/tomcat

    # Change that Tomcat instance to be owned by 'dspace' user

    $ sudo chown -R dspace:dspace /home/dspace/tomcat

After these steps, you would then have a Tomcat 7 instance installed at
/home/dspace/tomcat, owned by 'dspace'. This Tomcat 7 instance
essentially just references/calls back to the main Tomcat binaries in
/usr/share/tomcat7 (which are obviously managed/updated by the Ubuntu
package manager).

- Tim

On 6/5/2013 7:39 AM, Mark H. Wood wrote:

> On Wed, Jun 05, 2013 at 09:59:04AM +0200, Hilton Gibson wrote:
>> Hi Tim
>
> I'm not Tim, but here's my 2¢ worth anyway.
>
>> When creating the "dspace" user and then assigning this user the Tomcat6
>> account, how do we deal with file permissions needed by Tomcat6 for the
>> following system files;
>> *dspace@ir1:~$ dpkg -L tomcat6*
>> */.*
>> */usr*
>> */usr/share*
>> */usr/share/doc*
>> */usr/share/doc/tomcat6*
>> */usr/share/doc/tomcat6/changelog.Debian.gz*
>> */usr/share/doc/tomcat6/copyright*
>> */usr/share/tomcat6*
>> */usr/share/tomcat6/webapps*
>> */usr/share/tomcat6/webapps/default_root*
>> */usr/share/tomcat6/webapps/default_root/index.html*
>> */usr/share/tomcat6/webapps/default_root/META-INF*
>> */usr/share/tomcat6/webapps/default_root/META-INF/context.xml*
>> */var*
>> */var/cache*
>> */var/cache/tomcat6*
>> */var/log*
>> */var/log/tomcat6*
>> */var/lib*
>> */var/lib/tomcat6*
>> */var/lib/tomcat6/common*
>> */var/lib/tomcat6/common/classes*
>> */var/lib/tomcat6/server*
>> */var/lib/tomcat6/server/classes*
>> */var/lib/tomcat6/webapps*
>> */var/lib/tomcat6/shared*
>> */var/lib/tomcat6/shared/classes*
>> */etc*
>> */etc/init.d*
>> */etc/init.d/tomcat6*
>> */etc/tomcat6*
>> */etc/tomcat6/context.xml*
>> */etc/tomcat6/web.xml*
>> */etc/tomcat6/logging.properties*
>> */etc/tomcat6/policy.d*
>> */etc/tomcat6/policy.d/02debian.policy*
>> */etc/tomcat6/policy.d/50local.policy*
>> */etc/tomcat6/policy.d/03catalina.policy*
>> */etc/tomcat6/policy.d/01system.policy*
>> */etc/tomcat6/policy.d/04webapps.policy*
>> */etc/tomcat6/catalina.properties*
>> */etc/tomcat6/tomcat-users.xml*
>> */etc/tomcat6/Catalina*
>> */etc/tomcat6/Catalina/localhost*
>> */etc/tomcat6/server.xml*
>> */etc/cron.daily*
>> */etc/cron.daily/tomcat6*
>> */etc/default*
>> */etc/default/tomcat6*
>> */usr/share/doc/tomcat6/README.Debian.gz*
>> */var/lib/tomcat6/conf*
>> */var/lib/tomcat6/work*
>> */var/lib/tomcat6/logs*
>
> If your servlet container (e.g. Tomcat) already has an account, that
> account should own the DSpace files.  You only need to create a user
> "dspace" if you are installing Tomcat from source and can't decide
> what to name its account.  (In that case I would name it "tomcat" and
> let the DSpace files be owned by "tomcat".  There's nothing
> significant about a user named "dspace".)
>
> Anyway, whatever owns Tomcat should own DSpace and vice versa.  If
> your distribution creates an account when installing Tomcat, use that
> for DSpace as well.  Trying to make it work with two separate accounts
> is painful and unnecessary, as is trying to rejigger Tomcat to run as
> a different account than what your package manager used to install it.
>
> The DSpace documentation seems to assume that you are installing all
> prerequisites by hand and have no other use for Tomcat.  I've schemed
> to remold that section but haven't yet found an acceptable way to get
> rid of this confusing "dspace" user.  I continue to watch it from the
> shadows, devising strategems....
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
>
> _______________________________________________
> DSpace-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
> List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
DSpace-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Reply | Threaded
Open this post in threaded view
|

Re: DSpace Security

Francis Kayiwa
In reply to this post by Mark H. Wood
>
> If your servlet container (e.g. Tomcat) already has an account, that
> account should own the DSpace files.  You only need to create a user
> "dspace" if you are installing Tomcat from source and can't decide
> what to name its account.  (In that case I would name it "tomcat" and
> let the DSpace files be owned by "tomcat".  There's nothing
> significant about a user named "dspace".)
>
> Anyway, whatever owns Tomcat should own DSpace and vice versa.  If
> your distribution creates an account when installing Tomcat, use that
> for DSpace as well.  Trying to make it work with two separate accounts
> is painful and unnecessary, as is trying to rejigger Tomcat to run as
> a different account than what your package manager used to install it.

BOOM! *light bulb turns on!* Thanks a ton for this Mark. I learned
this "the hard way" and never did understand the motivation until now.
We happen to use a distro *cough cough* Red Hat ;-) that always
overwrote the permissions on upgrade and I can now safely purge my
"homegrown" scripts.


--
"Beer busts, beer blasts, keggers, stein hoists, A.A. meetings, beer
nights..." --Homer Simpson

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
DSpace-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette