[KLUG Members] RE: Effective file access responses

[Bob Kanaley]

Adam and Peter,

Thanks for the responses concerning my ignorance on effective file access.

A lot of the file access problems have come about because of the rapid
increase in company staff over the last two years. We have doubled in size
from 23 to 45 employees. With the growth, new departments are being created.
Job responsibilities are being shuffled. It is the need of new employees in
the new departments to access historical data that continues to be owned by
the original department that creates the file sharing nightmare. Of course
the original department wants to keep control of their historical data.
Thus, my departmental file sharing paradigm is being stretched out of shape.

> What version is your RedHat?  You may not even need to apply
> any kernel
> patches.  Does "rpm -q acl" return anything?  Rebuilding the Samba RPM
> to support ACLs (if it doesn't already) is truly trivial.
>

cat /etc/issue
RedHat 5.1(Manhattan)
Kernel 2.0.36 on an i686

rpm -q acl
Package not installed.

I believe it takes kernel 2.4.19+ to even be able to build a kernel with
ACL's.

I am still bumping along with our trusty VA Research Pentium Pro Raid 5
RedHat 5.1 Samba 1.9.18p5 file server (with oplocks turned off, thank you
very much). Our recently hired software engineer is busy programming open
source alternatives to our proprietary in-house software. For development
work, I gave him the dual power supply, dual NIC, Raid 1+0 with hot swap
spare, RedHat 7.2 ext3 box from Monarch.

>
> Sounds like a pretty normal setup.  Only I like to set "force group"
> instead of using SGID.
>

I ran into some problems when I apparently tried to make samba do more than
the linux file system permissions allowed. So I tend to make sure the file
system supports what I am trying to accomplish, then layer samba on top. If
I were doing it from scratch I would try the force group, I inherited much
of the samba settings. There are some strange global settings. Rather than
break something that is funky but working, I just used SGID to create the
new departments.

> >This setup seemed to work just fine for segregating
> department files but
> >allowed for simple read only sharing of department files.
>
> You could create something using the replacement characters %u, %G,
> etc...  Give each user another directory only they have write
> access to,
> and read access to anyone else.

Unfortunately, as I explained at the beginning of this email most of these
files are departmental files that have to stay available department wide.
New employees need read only access and sometimes write access even though
they are in a different department.

> >Unfortunately, I am getting more and more end user requests
> for access to
> >and sharing of files between specific individuals in
> different departments.
> >Depending on the access requested, I accommodate these
> requests in various
> >ways. For read only access, I simply put a link from the files in the
> >department share to the home directory of the requesting
> individual. This
> >seems pretty straightforward and reasonably safe.
>
> But it becomes impossible to maintain, depending upon the size of the
> network.  What happens when someone leaves, another user
> enters to mix?
>

Good point.
The company is still small enough that if someone leaves, the replacement
will need access to the same files. I guess at that point, I move the
symlinks to the new users home directory.

> >My concern is that with the proliferation of files appearing to be in
> >department locations that are actually owned by a
> non-departmental group, I
> >am going to give an unsophisticated user effective file
> access that would
> >allow accidental deletion of files in for example the
> company wide read only
> >share!!!
>
> One good idea would be to use the recycle VFS module to
> create a network
> trash can.  This gives you fall back protection against stupid users.

THIS IS MUST LEARN ABOUT!!!!

>
> You can give a user of group write access to files in a directory
> without giving them write access to the directory itself,  which might
> be what your looking for.
>

Are we talking samba permissions or Linux file permissions here?
I am not sure how this would be accomplished.


>
> Split up files so user roles are reflected in the physical structure.
> Spreadsheets can `include` other spreadsheets, etc...
>

Therein lies the problem. Business roles are being created and I have to
come up with access to a physical structure that was designed in a simpler
era.

> I'm afraid that with file sharing, without ACLs, all the
> solutions are a
> bit kludgy.

AMEN.



Peter,

>
> Have you tried isolating the needed files into a subdirectory and
> pointing a brand-new share with the necessary positions at
> that? So far
> as I know, there is no rule against pointing two shares into an
> overlapping tree.
>

This is the only way that I have been able to do things so far. However, I
have to create links back to the original department locations for the
unsophisticated users accessing these files on a daily basis. I came up with
the idea of putting  symlinks between the home and new location for the
non-department people simply to keep change to a minimum. Users don't like
change. Most know home and departmental directory. Unfortunately this means
create group, create subdirectory, assign group members, mv files, create
symlinks back to original location, then repeat for next case. I am
concerned with all the existing groups, newly created groups, symbolic
links, etc. I may end up giving someone the wrong kind of access to the
wrong files.

Hopefully, sometime this year I can get everyone moved over to the new file
server WITH a kernel that allows ACL's.

Thanks again for the help.

Bob

Robert V. Kanaley
Manager Information Systems
Agdia, Inc.
rvk@agdia.com
http://www.agdia.com