[KLUG Members] RE: Effective file access responses

Adam Williams members@kalamazoolinux.org
09 Feb 2003 19:17:01 -0500


>>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

Yikes!  

>rpm -q acl
>Package not installed.

Nope, no ACL support in a distro that old.

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

Something like that,  but most recent distros include it.

>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

Holy cow.  You do realize that sub-2.2.x isn't cleared to work with
WinNTsp6+, WinY2k, or WinXpee?  Of course, I've recently bumped into
several sites that are.  Updating Samba is really easy and may provide a
nice performance kick.

>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.

Nice, I don't recall if 7.2 included ACL support, but I really doubt
it.  You should update to 8.x prior to going production.  Many issues
have been resolved, performance is noticeably better, and the upgrade
should be relatively painless.

>>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

That version of Samba might be problematic when you start to do wierd
things.  

>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.

Hide files and veto files might be useful.  You can create multiple
shares that point to the same point but with differing veto settings,
etc... But I don't know how complicated your right assignments are.

>>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!!!!

It is very nice.

>>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.

Directory permissions of like r-x, gives read and scan, but not write. 
Thus you can open and modify files, but you can't create or delete files
in the directory.