How to set Permissions on New File

[Hal Vaughan]

I've been reading up on file permissions (including FilePermission,
Permission, and Permissions). From what I see, these are temporary and
forgotten when a program exits (if I'm wrong, tell me, please).

I'm installing a program on a computer and that includes configuration files
that change regularly. When I create the configuration files, I want them
to be readable and writable by any user running the program, otherwise my
program won't be able to function.

So how can I, from Java, find a way to set the permissions on a file I
create (from within Java) so all users can read and write that file
whenever they run the program?

My first thought was to have the program itself, whenever it was started,
set the permissions with a FilePermission object, but that doesn't make
sense -- if files are not readable or writable by a user, it wouldn't make
sense to allow that user to change the permissions.

Thanks for any info.

Hal

[Anthony Borla]

Hal,

"Hal Vaughan" <ha*@thresholddigital.com> wrote in message
news:GTmnb.46726$HS4.219485@attbi_s01...

I've been reading up on file permissions (including FilePermission,
Permission, and Permissions). From what I see, these are
temporary and forgotten when a program exits (if I'm wrong, tell
me, please).

They represent the access the current process and its children [i.e. your
running program] has to the specified files. In other words, they make sense
only in context of the current program, and, yes, do not actually alter any
system-level, file-specific attributes.

I'm installing a program on a computer and that includes
configuration files that change regularly. When I create the
configuration files, I want them to be readable and writable by
any user running the program, otherwise my
program won't be able to function.

This is easily achieved using the relevant operating system utility which is
nothing more than an interface to the relevant operating system function(s)
/ call(s) which actually perform such tasks. A system administrator would
normally call such utilities from a script file, or perhaps use a friendly
graphical interface to execute them.

For instance, on Windows-family systems the 'attrib' and 'cacls' utilities
would likely be used, while on *NIX and Linux systems the relevant utilities
are 'chmod' and 'chown'. In both cases, however, 'friendlier' utilities may
well exist.

So how can I, from Java, find a way to set the permissions
on a file I create (from within Java) so all users can read and
write that file whenever they run the program?

The simplest approach is to launch the relevant operating system utilities
from within your application via 'Runtime.exec'. Dig out the applicable
operating system manuals and start experimenting :)

A much cleaner approach is to use JNI routines which tap into the relevant
operating system functionality. A web search may help discover a suitable
library if this approach is preferred.

My first thought was to have the program itself, whenever it
was started, set the permissions with a FilePermission object,
but that doesn't make sense -- if files are not readable or writable
by a user, it wouldn't make sense to allow that user to change the
permissions.

Correct.

Thanks for any info.

I hope this helps.

Anthony Borla

[Hal Vaughan]

Thanks! It helps a lot.

I was looking at using native commands, since I couldn't find anything else.
For me, that is a last resort, since it means writing a special
implementation for each OS the installer works on, and I was hoping to keep
it as multi-platform as possible (part of the reason I'm using Java). At
least using chmod will work for most OSs out there and I have a book on
Windows scripting to take care of that.

You also provide a lot of useful and clear information. Your comments are a
big help and greatly appreciated.

Hal

Anthony Borla wrote:

Hal,

"Hal Vaughan" <ha*@thresholddigital.com> wrote in message
news:GTmnb.46726$HS4.219485@attbi_s01...

I've been reading up on file permissions (including FilePermission,
Permission, and Permissions). From what I see, these are
temporary and forgotten when a program exits (if I'm wrong, tell
me, please).

They represent the access the current process and its children [i.e. your
running program] has to the specified files. In other words, they make
sense only in context of the current program, and, yes, do not actually
alter any system-level, file-specific attributes.

I'm installing a program on a computer and that includes
configuration files that change regularly. When I create the
configuration files, I want them to be readable and writable by
any user running the program, otherwise my
program won't be able to function.

This is easily achieved using the relevant operating system utility which
is nothing more than an interface to the relevant operating system
function(s) / call(s) which actually perform such tasks. A system
administrator would normally call such utilities from a script file, or
perhaps use a friendly graphical interface to execute them.

For instance, on Windows-family systems the 'attrib' and 'cacls' utilities
would likely be used, while on *NIX and Linux systems the relevant
utilities are 'chmod' and 'chown'. In both cases, however, 'friendlier'
utilities may well exist.

So how can I, from Java, find a way to set the permissions
on a file I create (from within Java) so all users can read and
write that file whenever they run the program?

The simplest approach is to launch the relevant operating system utilities
from within your application via 'Runtime.exec'. Dig out the applicable
operating system manuals and start experimenting :)

A much cleaner approach is to use JNI routines which tap into the relevant
operating system functionality. A web search may help discover a suitable
library if this approach is preferred.

My first thought was to have the program itself, whenever it
was started, set the permissions with a FilePermission object,
but that doesn't make sense -- if files are not readable or writable
by a user, it wouldn't make sense to allow that user to change the
permissions.

Correct.

Thanks for any info.

I hope this helps.

Anthony Borla

[Phil...]

I thought JNI would not give the programm
more permissions than that of the user that
ran the program -- else anyone could rm -rf *
"Anthony Borla" <aj*****@bigpond.com> wrote in message
news:gJ*********************@news-server.bigpond.net.au...

Hal,

"Hal Vaughan" <ha*@thresholddigital.com> wrote in message
news:GTmnb.46726$HS4.219485@attbi_s01...

I've been reading up on file permissions (including FilePermission,
Permission, and Permissions). From what I see, these are
temporary and forgotten when a program exits (if I'm wrong, tell
me, please).

They represent the access the current process and its children [i.e. your
running program] has to the specified files. In other words, they make

sense only in context of the current program, and, yes, do not actually alter any system-level, file-specific attributes.

I'm installing a program on a computer and that includes
configuration files that change regularly. When I create the
configuration files, I want them to be readable and writable by
any user running the program, otherwise my
program won't be able to function.

This is easily achieved using the relevant operating system utility which

is nothing more than an interface to the relevant operating system function(s) / call(s) which actually perform such tasks. A system administrator would
normally call such utilities from a script file, or perhaps use a friendly
graphical interface to execute them.

For instance, on Windows-family systems the 'attrib' and 'cacls' utilities
would likely be used, while on *NIX and Linux systems the relevant utilities are 'chmod' and 'chown'. In both cases, however, 'friendlier' utilities may well exist.

So how can I, from Java, find a way to set the permissions
on a file I create (from within Java) so all users can read and
write that file whenever they run the program?

The simplest approach is to launch the relevant operating system utilities
from within your application via 'Runtime.exec'. Dig out the applicable
operating system manuals and start experimenting :)

A much cleaner approach is to use JNI routines which tap into the relevant
operating system functionality. A web search may help discover a suitable
library if this approach is preferred.

My first thought was to have the program itself, whenever it
was started, set the permissions with a FilePermission object,
but that doesn't make sense -- if files are not readable or writable
by a user, it wouldn't make sense to allow that user to change the
permissions.

Correct.

Thanks for any info.

I hope this helps.

Anthony Borla

[Anthony Borla]

Phil,

"Phil..." <ry***@ieee.org> wrote in message
news:rAxnb.51456$HS4.234306@attbi_s01...

I thought JNI would not give the programm
more permissions than that of the user that
ran the program -- else anyone could rm -rf *

JNI simply allows you to tap into functionality not offered in Java. When
using JNI you bypass the JVM, and surrender control of you application to
'foreign' code, code which can pretty well do anything it wants *within
operating system constraints* !

The JVM and application execute within the context of a user account [or
similar], and are bound by the security and other restrictions imposed on
that account. So, to use your example, a JNI routine may possibly allow you
to perform the equivalent of a 'rm -rf', but unless the user account [or
similar] has the requisite permission(s), the attempt will fail with the
operating system 'trapping' the attempt, and somehow handling / logging it.
A JNI routine will, to be considered robust, handle such possibilities
predictably and gracefully allowing the application to handle the situation
as required.

It may help to think of an [Java] application's [not applet] execution
environment as a layered entity, somewhat like an onion. The application
executes under the supervision and control of the JVM but may, using
facilities like JNI, temporarily bypass that layer when necessary. When
doing so it will encounter the operating system layer, typically the
security a sub-system. In either case the application is bound by the
constraints imposed by that layer, constraints which would normally have
been imposed *before* application execution, and [probably] cannot be
altered without a restart.

I hope this helps.

Anthony Borla

[Anthony Borla]

Hal,

"Hal Vaughan" <ha*@thresholddigital.com> wrote in message
news:FLvnb.38539$ao4.82577@attbi_s51...

Thanks! It helps a lot.

A pleasure :) !

I was looking at using native commands, since I couldn't
find anything else. For me, that is a last resort, since it means
writing a special implementation for each OS the installer works
on, and I was hoping to keep it as multi-platform as possible
(part of the reason I'm using Java). At least using chmod will
work for most OSs out there and I have a book on
Windows scripting to take care of that.

Application installation [as opposed to applet installation] is inherently
operating-system specific [just look at all those .tar and .zip files out
there in cyberspace !]. It certainly pays to be familiar with all the
installation-related utilities, and scripting facilities offered by the
target platforms.

You also provide a lot of useful and clear information.Your
comments are a big help and greatly appreciated.

My belief is to try [where possible, and, of course, relavant] to explain
general principles in forum responses. After all, answers to very-specific
questions can easily be obtained from text books and manuals [not to mention
Google searches :) !].

Cheers,

Anthony Borla

[Hal Vaughan]

Anthony Borla wrote:

Hal,

"Hal Vaughan" <ha*@thresholddigital.com> wrote in message
news:FLvnb.38539$ao4.82577@attbi_s51... <snip>

You also provide a lot of useful and clear information.Your
comments are a big help and greatly appreciated.

My belief is to try [where possible, and, of course, relavant] to explain
general principles in forum responses. After all, answers to very-specific
questions can easily be obtained from text books and manuals [not to
mention Google searches :) !].

It is much appreciated. Although I had tried several Google searches and
some other research, I didn't find anything that specifically told me I
could not do what I wanted in Java, so getting a full answer was definately
helpful. Your extra effort is a big help (and I'm sure, one day, it'll
help someone else who finds this thread in a Google search).

Hal
Cheers,

Anthony Borla