Hi,

Apologies if anyone has read my recent post on the same subject in the Linux forum, just thought actually the solution might more likely come from scripting.

Essentially, I am trying to restrict access to directories based on the user's name AND their location on a session-by-session basis (ie a user can walk down the corridor and start a new software session). My software, which kicks off a .sh file, knows where the user is located, so there can be a flag in the .sh file with a known value for user location.

So all I hopefully need is a set of logic in my .sh file that converts this flag into making a set of directories (say those owned by a deptA group) not available in a deptB session (ie my software won't know/have permissions on these directories). Is this possible?

The deptA directories could be on a separate mount to deptB's, so could a whole mounted be hidden in a particular session?

Thanks for looking,

Steve

Deny execute access to users in group DeptA on /filesystem1, grant execute access to DeptB on /filesystem1.

Have no world (or other) access on /filesystem1. Put all of DeptA into a single group, put all of DeptB into a separate group.

If your filesystems support acl's you can block access using acl's on a per user basis if you want. You only need to block access department-wide at one point -one directory - then all subsequent directories become unreachable. See man chacl

Jim,

Thanks for the reply.

However, is this giving rise to the dynamic permissions required? IE userA starts a session while physically sitting in deptA (which the software knows and passes to the .sh file) and can see deptA filesystem. Then same userA walks down the corridor to deptB and starts a session, and this time shouldn't be able to see deptA filesystem.

Is chroot a possible solution to this? Only just found it, so just looking over its potential now.

Thanks,

Steve

How about SELinux? Could this do the trick? I am running on RHEL 4.

Again, I am just googling around and came across this. Could a .sh file be called twice to start up 2 sessions of the software, but each having a different context accoring to the SELinux permissions: one for deptA, the other for deptB?

Steve