File Name Write Restriction

[Brahnda Eleazar]

Peace all,

There was a security "inquiry" as whether we can restrict a user in HP-UX so that this user can only write/create certain file names.

For example, user001 can only create file F001 and it cannot be used to create F002 even though it is granted write access to the target directory. File F002 can only be created using user002 for example.

Is this possible? If it is not, I was thinking of doing it by cron; but if there's anything more "real time", please share :)

Thanks,
=adley=

[Dennis Handly]

I'm not aware of anything other than enforcement after the fact. I'm not sure auditing, audsys(1m), would help.

[Brahnda Eleazar]

Peace Dennis Handly,

I don't think audsys is applicable here. The background for this "inquiry" was because of applications located on a number of remote sites that need to do SFTP to the central office.

Each site will have a unique file name associated with it and thus the "inquiry" comes in :) Each site should only be able to write the files associated with it and no other :)

I'm still confused on what to do. If not by cron, perhaps I can prepare all of the possible file names and map them to the correct users as proper owners so that overwriting will be restricted. But this doesn't solve the problem relates to creating new file names not yet defined :)

=adley=

[Steven Schweda]

Perhaps you could create all the files first,
and give each of them an ACL to provide write
permission only for the desired user.

Normally, one provides each user with a
separate directory (with limited write
permission), and then looks in all of them to
collect all the results. (Which is easy on
VMS, but less so on UNIX.)

I suspect that you have a problem which is
better solved in some other way, but if you
ask how to implement a bad solution instead
of how best to solve the real problem, then
you tend to get sub-optimal suggestions.

[Andrew Young_2]

Hi.

The short answer is no. The correct answer however is that with a lot of work just about anything is possible. However it would not be an OS solution but another application to handle the file transfer or creation and validation.

To restrict a remote users ability to write certian files with a given file mask would need a new shell or communications protocol to handle the server side of things. There are products that do this sort of thing already, Sterling Commerce's Connect Direct used by many financial institutions is one that comes to mind. Essentially what happens is that the files from each client are copied to the destination server then a server side validation script is run and validates the data and moves it to the final destination if needed.

HTH

Andrew Y

[Hemmetter]

Hi

Another commercial product Fujitsu-Siemens "OpenFT".

http://www.fujitsu-siemens.com/products/software/openseas/openft.html

Is is available for many UNIX and Unix-like, Windows and some more.

rgds
HGH

[Steven Schweda]

> [...] perhaps I can prepare all of the
> possible file names [...]

It might be better to create a directory for
each user, with write permission for only
that user (perhaps something under each
user's home directory), and require that all
files be transferred to those directories.
That should satisfy the exclusive write
permission requirement.

Then, you can run a script (periodically,
using "cron", or however) which can look
through those user-specific directories and
move the files which you wish to move to
their ultimate destinations. You could, for
example, take each user name, remove the
"user" part, and look for "*${remainder}"
("*002", say) in the user's special transfer
directory. It's not classy, but it should be
fairly easy to implement.

[Brahnda Eleazar]

Peace Steven,

Ideally, it is just you said -- limit a user to a certain directory. However, the application to be implemented cannot behave like that, at least not without a lot of changes and I don't think the developers have enough time to do those changes as per the current situation here :)

Preparing the files first seem to be the easiest way, and combining it with a cron for cleanup/monitoring might work.

=adley=

[Steven Schweda]

> [...] the application to be implemented
> cannot behave like that [...]

Perhaps not, but when you don't specify the
constraints on the application's behavior, it
can be hard to make the right guesses.
Knowing nothing about how these files are
being created, it's difficult to distinguish
easy from impractical or impossible. For
example, "the target directory" could be
specified in any number of ways, some of
which would be helpful, while others would
pose obstacles. (I have a suspicion that on
VMS, logical names might simplify things
considerably, but on HP-UX, you're left with
things like symbolic links and chroot(),
which may or may not be helpful.)

[A. Clay Stephenson]

There is nothing in UNIX to do this nor should there be. This should be solely a function of the application and should have been specified when the application was designed. Anything other than an application change is throwing a Band-Aid at the problem.

I assume that someone approved this application design; that is where the responsibility lies.

[Dennis Handly]

Steven: you're left with things like symbolic links

One idea with symlinks is use a symlink for the application that points into the private directory.

So the application sees a central directory, one symlink for each user. But each user can only write to their subdirectory.

[Bill Hassell]

It sounds like the users are not properly trained in Unix but have been given shell access. That is the real problem. You need to take away shell access and replace their login program with a menu that only gives them the tasks that you define. That way, they can never make a mistake and you won't have to find and workaround endless shell issues for untrained users.

[Brahnda Eleazar]

Peace all,

Thanks for the replies.
Well, the topic of enhancing the application a bit has come to reality somehow (yaayy :))

Hopefully, this time my concerns regarding this will be heard :)

=adley=