Overview


limetech

Recommended Posts

This will eventually make it's way to the Wiki, but for now, here's an overview of the 5.0 share security model.


Shares

 

There are three types of shares:

- disk shares

- flash share

- user shares, or just 'shares'.

 

The disk shares are automatically generated by the server and map directly to each of the array data disks.  The names of these shares are "disk1", "disk2", etc.

 

The flash share is also automatically generated by the server and maps directly to the USB flash device from which the system is booted.  The name of this share is "flash".

 

User shares are shared created by the user.

 

Security

 

Each share has it's own security settings.  The security settings for a share include it's Export setting and its Security Mode setting.

 

The share Export setting determines overall visibility of the share:

- Export=Yes means the share is visible in browse list and is accessible per it's security mode.

- Export=No means the share is not visible and not accessible regardless of the security mode, that is, effectively disabled.

- Export=Yes/hidden means the share is not visible in Windows CIFS networking, but is accessible per it's security mode.

 

The Security Mode setting establishes access rights to the share. There are three security modes for a share:

- Public

- Secure

- Private

 

Public means that no user account is needed on the server for someone to access the share.  This means you won't see the login box pop up when accessing the share.  It also means that anyone can read/write/create/delete any file or directory on the share.  This is the default setting when a new share is created.  This is also the default setting if a share is created by creating it on a disk share.  When a file is created it will be be owned on the linux-side by the 'nobody' user of the users group (uid/gid = 99/100).

 

Secure means that no user account is necessary on the server in order to access the share, and no login box will pop up.  But in this mode you can select users than can have read/write access to the share, all other users will have read-only access.  Since no login box will appear, in order to get this to work, this must be true:

- Whatever username you used to log in to your windows PC must also be a user name on the server.  The 'case' of the user name does not matter (actually you must enter all lower-case on server side).

- The password you set on the server must match exactly the password used for your windows logon.  The password IS case-sensitive.

 

Private means that you specify the exact set of users that can either have readonly or read/write access to the share.  If you try to connect to the server you may or may not get a login box.  If the username/password of your windows login matches one of the usernames defined on the server side, and that username has either readonly or read/write access (ie, not 'no access), then no login box will appear and you will be be logged into the share with the access rights specified.  But if either your windows username is unknown on the server, or your windows password does not match, then windows will present a login box prompting for a username/password.  Using this box you can then login to the share using one of the other username/passwords on the server.

 

Note that once you login to the server using some other username than your windows username, windows will use that username to access all shares on the server.

 

samba details

  create mask = 770

  directory mask = 770

  guest account = nobody (this is the samba default)

 

All files will be in the 'users' group (gid=100).  Files created under security modes public or secure will be created with the 'nobody' user (uid=99/gid=100).  Files created under security mode private will be owned by that user (uid=1000+/gid=100).  "Ownership" is actually inconsquential since all users are in the same group (the 'users' group) and the group rw permissions are always set.

 

An issue arises with dos attributes.  Normal way is for samba to map:

  readonly - mapped to ugo 'w' permissions

  archive - mapped to u 'x'

  system - mapped to g 'x'

  hidden - mapped to o 'x'

Mapping to the 'w' permission is ok, but mapping to the 'x' bits is a problem for non-samba protocols (eg, afp).

 

Samba provides the 'store dos attributes' parameter to store these bits in an extended attribute, but I have had problems getting this to work (won't work for some reason).

 

Therefore, I have settled on the following compromise for the time being:

- only windows 'readonly' attribute will work, and it will be mapped to the ugo 'w' permissions (actually only u and g).

- the other attributes, archive/hidden/system can never be set.

 

If this proves to be a problem, perhaps I can reinvestigate why 'store dos attributes' doesn't work and/or provide a configuration parameter to map the hidden/system/archive bits in the usual manner, ie, to the 'x' bits.  The main problem I see is that 'hidden' files will always be shown in windows directory listings [maybe a benefit?].  There also might be some programs out there that depend on proper function of the archive bit.

 

NFS

 

Note: NFS support isn't fully tested so it's inactive in -beta1.

 

The problem with NFS is that there is no user authentication.  Therefore, NFS has these restrictions with each of the security modes:

- if share Export is 'No' then share can't be accessed at all

- security mode 'Public': any NFS client can read/write the share (this is mapped to user 'nobody' as with Samba guest access).

- security mode 'Secure': any NFS client can read the share, no NFS client can write the share.  In other words, share appears to be read-only to all NFS clients.

- security mode 'Private': any NFS client with uid/gid matching a user on the server will be able to read/write any share.  It is not possible to restrict which users have only readonly access, so it's not really private in this sense.  Use this with caution.

 

NFS details

- we create a directory called /nfs which contains symlinks to each share marked as Export=Yes.  For each exported share, we create an entry in the exports file like this:

 

For mode Public:

/nfs/<name> *(rw,no_subtree_check,insecure,anonuid=99,anongid=100,all_squash)

 

For mode Secure:

/nfs/<name> *(ro,no_subtree_check,insecure,anonuid=99,anongid=100,all_squash)

 

For mode Private:

/nfs/<name> *(rw,no_subtree_check,insecure,root_squash)

 

In this mode the uid/gid of the NFS client must match one of the servers username uid/gid, but if it does, that client has full read/write access to the share.  This is because all users on the server are in the same group ('users'), and the group permission bits are set to 'rw'.

 

Link to comment

Therefore, I have settled on the following compromise for the time being:

- only windows 'readonly' attribute will work, and it will be mapped to the ugo 'w' permissions (actually only u and g).

- the other attributes, archive/hidden/system can never be set.

 

If this proves to be a problem, perhaps I can reinvestigate why 'store dos attributes' doesn't work and/or provide a configuration parameter to map the hidden/system/archive bits in the usual manner, ie, to the 'x' bits.

 

From my perspective, I can safely say that's OK by me.  The only possible use I have for those attributes is when doing some type of backup from some type of DOS/WIN system and restoring it.  But in that case, I'm going to use some type of imaging system, (for whole disk backups) or if just backing up one dir structure, I'm using zip/rar tools.

 

I can imagine some scenarios where those attributes would be needed, but they all involve stuff that is most likely to be done by someone with experience, and who can easily work around them.

Link to comment
  • 4 years later...

This will eventually make it's way to the Wiki, but for now, here's an overview of the 5.0 share security model.


Shares

 

There are three types of shares:

- disk shares

- flash share

- user shares, or just 'shares'.

 

The disk shares are automatically generated by the server and map directly to each of the array data disks.  The names of these shares are "disk1", "disk2", etc.

 

The flash share is also automatically generated by the server and maps directly to the USB flash device from which the system is booted.  The name of this share is "flash".

 

User shares are shared created by the user.

 

Security

 

Each share has it's own security settings.  The security settings for a share include it's Export setting and its Security Mode setting.

 

The share Export setting determines overall visibility of the share:

- Export=Yes means the share is visible in browse list and is accessible per it's security mode.

- Export=No means the share is not visible and not accessible regardless of the security mode, that is, effectively disabled.

- Export=Yes/hidden means the share is not visible in Windows CIFS networking, but is accessible per it's security mode.

 

The Security Mode setting establishes access rights to the share. There are three security modes for a share:

- Public

- Secure

- Private

 

Public means that no user account is needed on the server for someone to access the share.  This means you won't see the login box pop up when accessing the share.  It also means that anyone can read/write/create/delete any file or directory on the share.  This is the default setting when a new share is created.  This is also the default setting if a share is created by creating it on a disk share.  When a file is created it will be be owned on the linux-side by the 'nobody' user of the users group (uid/gid = 99/100).

 

Secure means that no user account is necessary on the server in order to access the share, and no login box will pop up.  But in this mode you can select users than can have read/write access to the share, all other users will have read-only access.  Since no login box will appear, in order to get this to work, this must be true:

- Whatever username you used to log in to your windows PC must also be a user name on the server.  The 'case' of the user name does not matter (actually you must enter all lower-case on server side).

- The password you set on the server must match exactly the password used for your windows logon.  The password IS case-sensitive.

 

Private means that you specify the exact set of users that can either have readonly or read/write access to the share.  If you try to connect to the server you may or may not get a login box.  If the username/password of your windows login matches one of the usernames defined on the server side, and that username has either readonly or read/write access (ie, not 'no access), then no login box will appear and you will be be logged into the share with the access rights specified.  But if either your windows username is unknown on the server, or your windows password does not match, then windows will present a login box prompting for a username/password.  Using this box you can then login to the share using one of the other username/passwords on the server.

 

Note that once you login to the server using some other username than your windows username, windows will use that username to access all shares on the server.

 

samba details

  create mask = 770

  directory mask = 770

  guest account = nobody (this is the samba default)

 

All files will be in the 'users' group (gid=100).  Files created under security modes public or secure will be created with the 'nobody' user (uid=99/gid=100).  Files created under security mode private will be owned by that user (uid=1000+/gid=100).  "Ownership" is actually inconsquential since all users are in the same group (the 'users' group) and the group rw permissions are always set.

 

An issue arises with dos attributes.  Normal way is for samba to map:

  readonly - mapped to ugo 'w' permissions

  archive - mapped to u 'x'

  system - mapped to g 'x'

  hidden - mapped to o 'x'

Mapping to the 'w' permission is ok, but mapping to the 'x' bits is a problem for non-samba protocols (eg, afp).

 

Samba provides the 'store dos attributes' parameter to store these bits in an extended attribute, but I have had problems getting this to work (won't work for some reason).

 

Therefore, I have settled on the following compromise for the time being:

- only windows 'readonly' attribute will work, and it will be mapped to the ugo 'w' permissions (actually only u and g).

- the other attributes, archive/hidden/system can never be set.

 

If this proves to be a problem, perhaps I can reinvestigate why 'store dos attributes' doesn't work and/or provide a configuration parameter to map the hidden/system/archive bits in the usual manner, ie, to the 'x' bits.  The main problem I see is that 'hidden' files will always be shown in windows directory listings [maybe a benefit?].  There also might be some programs out there that depend on proper function of the archive bit.

 

NFS

 

Note: NFS support isn't fully tested so it's inactive in -beta1.

 

The problem with NFS is that there is no user authentication.  Therefore, NFS has these restrictions with each of the security modes:

- if share Export is 'No' then share can't be accessed at all

- security mode 'Public': any NFS client can read/write the share (this is mapped to user 'nobody' as with Samba guest access).

- security mode 'Secure': any NFS client can read the share, no NFS client can write the share.  In other words, share appears to be read-only to all NFS clients.

- security mode 'Private': any NFS client with uid/gid matching a user on the server will be able to read/write any share.  It is not possible to restrict which users have only readonly access, so it's not really private in this sense.  Use this with caution.

 

NFS details

- we create a directory called /nfs which contains symlinks to each share marked as Export=Yes.  For each exported share, we create an entry in the exports file like this:

 

For mode Public:

/nfs/<name> *(rw,no_subtree_check,insecure,anonuid=99,anongid=100,all_squash)

 

For mode Secure:

/nfs/<name> *(ro,no_subtree_check,insecure,anonuid=99,anongid=100,all_squash)

 

For mode Private:

/nfs/<name> *(rw,no_subtree_check,insecure,root_squash)

 

In this mode the uid/gid of the NFS client must match one of the servers username uid/gid, but if it does, that client has full read/write access to the share.  This is because all users on the server are in the same group ('users'), and the group permission bits are set to 'rw'.

 

Hi, do this rules still apply in v6b?

Rgds.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.