Koozali.org: home of the SME Server

file/directory level user and group permissions, not share l

Patrick Basile

file/directory level user and group permissions, not share l
« on: February 11, 2002, 07:27:33 PM »
Hello everyone,

I'd like to see file/directory level user and group permissions, instead of the "share" level permissions now used with i-bays.  Having to settle for "share" level access control is real step backwards for folks trying to replace NT4/Win2k servers with SME.

Anyone else have thoughts on this topic?  Experiences to share?  Solutions for this "real world" problem?  Thanks.

Regards,
Patrick

Patrick Basile

nobody else deals with this??? Re: file/directory level use
« Reply #1 on: February 28, 2002, 11:44:34 AM »
Doesn't anyone else deal with this issue?!?  I'm astounded that more of you aren't asking about better file/directory permisions.  Other thoughts?  Ideas?

How are all the rest of you dealing with specific file and directory/sub-directory security issues?  It's a little tough to get "real" security and permissions set at the i-bay ("share") level!

Devlyn Davis

Re: file/directory level user and group permissions, not sha
« Reply #2 on: March 06, 2002, 10:12:56 AM »
I agree with this.  I'm trying to relate SME with my current NT/2K admin experience.  I can see offering customers this solution because, for the most part, SME really rocks, but the file/directory/user/group permissions is something of a sticking point.  

What happens if you want to create a directory where a bunch of users can access it, but only certain users can modify/change data.  What about if you want to create subfolders in a share where some users can access it and others cannot.  There needs to be a clear and concise way to apply permissions on files, folders, and directories.  The only option now is to create a massive amount of groups and shares.  I feel that will annoy users, having to keep jumping around between folders.

Anyway, is there a way to implement this within the current framework?

-Devlyn

Patrick Basile

Re: file/directory level user and group permissions, not sha
« Reply #3 on: March 06, 2002, 09:26:23 PM »
Devlyn,

Thanks for your response!  I was wondering when someone else was going to add their own "real world" perspective to this thread.  I am still amazed at the lack of response from the rest of the SME community.  Aren't there any other current/former Windoze NT4/2000 sys admins dealing with this issue?

You hit the nail on the head with this comment - "What about if you want to create
subfolders in a share where some users can access it and others cannot.  There needs to be a clear and concise way to apply permissions on files, folders, and directories."

I hope the SME developers or other folks respond to this - I think there must be MANY other sys admins like us who are looking at this solid product (it does rock in most areas!) and wonder why it is lagging in the file/directory/user/permissions area.

Regards,
Patrick

Graeme Robinson

Re: file/directory level user and group permissions, not sha
« Reply #4 on: March 07, 2002, 12:39:33 AM »
As an administrator I have to say that I disagree that what is suggested here is a good idea.  The key statement is:

"There needs to be a clear and concise way to apply permissions on files, folders, and directories"

There is and the current system is, IMO, it.

Creating new levels of granularity of permissions within ibays is adding a far greater complexity and potential for user confusion and admin frustration than creating as many ibays & groups as are required.

Having said that, if you really believe this is a good idea, and want it to happen you have several options available to you:

1. Keep whining about it here and hope that Mitel listen.
2. Contact your local Mitel partner and register a server - then request it.
3. join the Samba development team and contribute to the development of this functionality or petition them directly.
4. Contact Mitel directly and arrange for development of this functionality as part of their proffessional service offering.

1 = least likely to change anything
2 = more likely as registered customers are always listened to more than unregistered users of SME, but as the issue is embedded in the development of Samba itself, still not likely to get a result.
3 = best chance of success as what you are requesting is dependent on the development of Samba, the windows file-sharing protocol used by ibays.
4 = unlikely Mitel would agree given that development of Samba is they key, but if they did then this is likely to be the quickest path to your solution.

Devlyn Davis

Re: file/directory level user and group permissions, not sha
« Reply #5 on: March 07, 2002, 03:58:43 AM »
Graeme,

I agree with most of what you say, but the problem I see is in 'fine tuning' permissions.  Currently, Samba/SME only offers fairly wide strokes.  I can appreciate the complexity it designing the software, but that does not change the fact that Windows and Novell offer a far wider set of tools for assigning permissions for users/objects/groups/etc.


"Creating new levels of granularity of permissions within ibays is adding a far greater complexity and potential for user confusion and admin frustration than creating as many ibays & groups as are required."

I'm going to have to respectfully disagree.  I think the opposite is true.  Requiring a user to access many different folders would seem to be more complex, in my opinion.  

Now I will qualify what I've said by saying that I have not admined SME in a production evironment as of yet.  I am also not a Linux or Samba expert.  However, I have become fans of both Linux and SME and my opinions may change as I gain more experience.

-Devlyn

Patrick Basile

Re: file/directory level user and group permissions, not sha
« Reply #6 on: March 07, 2002, 07:09:23 AM »
Okay...well here goes a few 'follow up' thoughts.

Devlyn Davis wrote:
> that Windows and Novell offer a far wider set of tools for
> assigning permissions for users/objects/groups/etc.

When compared to Windoze in the file permissions/share area - there is no question SME falls short (sorry guys...luv the product, but I call a spade a spade).  For those of us with experience running NT/2K this feels like a step back to Windows 9x peer-to-peer file shares.  Now for the qualification - there may in fact be other Linux distros and/or tools that handle this task in a better way than SME.  If so, perhaps the Mitel/SME development group should take a look at those products.

> "Creating new levels of granularity of permissions within
> ibays is adding a far greater complexity and potential for
> user confusion and admin frustration than creating as many
> ibays & groups as are required."
>
> I'm going to have to respectfully disagree.  I think the
> opposite is true.  Requiring a user to access many different
> folders would seem to be more complex, in my opinion.

There is no question that the SME file permissions/i-bay setup (read "lots more mapped drives to "shares"/i-bays) is a more complex model for the end user.  Most end users have a tough enough time when you tell them to "...put the file in your F: drive under the {insert folder name} folder."  Many end users don't understand file/folders(directories) - or "shares" and mapped drives, etc.  In my 9 years of end user support I have consistently run into this roadblock - and educating end users is a constant task and struggle.

The end user needs it to be EASY, and easy to them is a whole different thing than what us techies consider easy.  For example, a single mapped drive to a properly configured share with the correct file/user/group permissions is by far the easiest for an end user.  I can imagine the confusion if I mapped a dozen different drives on my end user machines...I'd be getting calls all day about where to put what and why are there so many drives.

> Now I will qualify what I've said by saying that I have not
> admined SME in a production evironment as of yet.

Over the past 6 months I have setup and currently help to or directly administer 4 SME servers in several small business (less than 25 clients).  Although this is not a lengthy production experience, it's plenty for me to get a "real world" feel for how SME works.  Overall it works great - period!  When compared to Windoze NT/2K there are a few things that are rough around the edges, and this just happens to be one of those things.

> I am also not a Linux or Samba expert.  However, I have become fans of
> both Linux and SME and my opinions may change as I gain more
> experience.

I also am not an expert in these areas, but with each passing day I am finding more and more to like about Linux/SME.  The Samba team has done some amazing things to engineer the networking integration they have into Samba - no question.  Kudos also to the Mitel/SME group and all those other 'volunteers' like Darrell May and Dan Brown, who have developed an amazing product.  You have set a high standard, so it's no wonder those of us using the product are clamoring for even greater things!  ;)

Thanks for listening...I know that was more than 2 cents.

Regards,
Patrick

Charlie Brady

Re: file/directory level user and group permissions, not sha
« Reply #7 on: March 11, 2002, 03:54:12 AM »
Devlyn Davis wrote:

> What happens if you want to create a directory where a bunch
> of users can access it, but only certain users can
> modify/change data.

The problem here is that the Unix  file permissions system doesn't cater for that situation. There are not separate read groups and write groups associated with files and directories. There is recent work which adds full Access List (ACL) to the linux ext2 file system and to samba, but it is not widely deployed.

> There needs to be a clear and concise way to
> apply permissions on files, folders, and directories.

For it to be appropriate for i-bays, it would need to apply across the board to ftp, www, Mac filesharing and windows file sharing.

> The only option now is to create a massive amount of groups and
> shares.

Only if you have a massive number of access list combinations. Most sites don't.

> Anyway, is there a way to implement this within the current
> framework?

Not that I know of. Providing such fine grained control would be very difficult to do while remaining simple and clear.

Regards

Charlie

Greg O

Re: file/directory level user and group permissions, not sha
« Reply #8 on: May 28, 2002, 02:34:11 PM »
>
> There is no question that the SME file permissions/i-bay
> setup (read "lots more mapped drives to "shares"/i-bays) is a
> more complex model for the end user.  Most end users have a
> tough enough time when you tell them to "...put the file in
> your F: drive under the {insert folder name} folder."  Many
> end users don't understand file/folders(directories) - or
> "shares" and mapped drives, etc.  In my 9 years of end user
> support I have consistently run into this roadblock - and
> educating end users is a constant task and struggle.
>
Then why bother users with this concept of 'letter drives'? If I tell a user their files are under "schooladmin" or "secondary", then they'll click on "schooladmin" or "secondary" and there they are. Everyone can understand a folder and a file - I use the "filing cabinet" analogy.


> The end user needs it to be EASY, and easy to them is a whole
> different thing than what us techies consider easy.  For
> example, a single mapped drive to a properly configured share
> with the correct file/user/group permissions is by far the
> easiest for an end user.  I can imagine the confusion if I
> mapped a dozen different drives on my end user machines...I'd
> be getting calls all day about where to put what and why are
> there so many drives.
>
Then adjust your thinking of the SME method back a step. ie, call your 'letter drive' the server (can't be mapped, but can certainly have a shortcut to it under everyone's profile somewhere), and then all of your 'folders' (ibays) are to be found, each with permissions set as per SME's server-manager. It works for us (although the 28-groups limit is a pain - or has that been changed? *hopes desperately*), with ~40 machines and ~100 users. You can even name this shortcut to the server a single letter if you must.

Of course, there are problems with some (grrr) programs not handling UNCs properly (as opposed to letter drives). In those cases I've had to map a drive, but I keep the number of mapped drives to a bare minimum (about 3).


Greg.