glusterfs.git/xlators/protocol/server/src, branch v3.7.6

server/protocol: option for dynamic authorization of client permissions

2015-10-13T16:05:37+00:00

problem:
assuming gluster volume is already mounted (for gfapi: say client transport
connection has already established), now if somebody change the volume
permissions say *.allow | *.reject for a client, gluster should allow/terminate
the client connection based on the fresh set of volume options immediately,
but in existing scenario neither we have any option to set this behaviour nor
we take any action until and unless we remount the volume manually

solution:
Introduce 'dynamic-auth' option (default: on).
If 'dynamic-auth' is 'on' gluster will perform dynamic authentication to
allow/terminate client transport connection immediately in response to
*.allow | *.reject volume set options, thus if volume permissions have changed
for a particular client (say client is added to auth.reject list), his
transport connection to gluster volume will be terminated immediately.

Backport of:
> Change-Id: I6243a6db41bf1e0babbf050a8e4f8620732e00d8
> BUG: 1245380
> Signed-off-by: Prasanna Kumar Kalever 
> Reviewed-on: http://review.gluster.org/12229
> Tested-by: NetBSD Build System 
> Reviewed-by: Raghavendra G 
> (cherry picked from commit 84e90b756566bc211535a8627ed16d4231110ade)

Change-Id: If7e5c9be912412ea388391ef406ee2c8bedb26b8
BUG: 1271065 
Signed-off-by: Prasanna Kumar Kalever 
Reviewed-on: http://review.gluster.org/12343
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

protocol/server : porting missing gf_log's to gf_msg

2015-08-31T09:45:09+00:00

        Backport of http://review.gluster.org/#/c/11895/

Cherry-picked form commit a26dbb38acdb2ec5fe16068caee189709faae76e
> Change-Id: I8818931fafea3c013551a5de23a9f77c81164841
> BUG: 1252808
> Signed-off-by: Manikandan Selvaganesh 
> Reviewed-on: http://review.gluster.org/11895
> Tested-by: NetBSD Build System 
> Reviewed-by: Raghavendra G 

Change-Id: I8818931fafea3c013551a5de23a9f77c81164841
BUG: 1257193
Signed-off-by: Manikandan Selvaganesh 
Reviewed-on: http://review.gluster.org/12018
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G

protocol/server: forget the inodes which got ENOENT in lookup

2015-08-21T11:48:48+00:00

                 Backport of http://review.gluster.org/11489

If a looked up object is removed from the backend, then upon getting a
revalidated lookup on that object ENOENT error is received. protocol/server
xlator handles it by removing dentry upon which ENOENT is received. But the
inode associated with it still remains in the inode table, and whoever does
nameless lookup on the gfid of that object will be able to do it successfully
despite the object being not present.

For handling this issue, upon getting ENOENT on a looked up entry in revalidate
lookups, protocol/server should forget the inode as well.

Though removing files directly from the backend is not allowed, in case of
objects corrupted due to bitrot and marked as bad by scrubber, objects are
removed directly from the backend in case of replicate volumes, so that the
object is healed from the good copy. For handling this, the inode of the bad
object removed from the backend should be forgotten. Otherwise, the inode which
knows the object it represents is bad, does not allow read/write operations
happening as part of self-heal.

Change-Id: I268eeaf37969458687425187be6622347a6cc1f1
BUG: 1255604
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11973
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created

2015-08-14T08:12:41+00:00

           Backport of http://review.gluster.org/11718

This test sets the lru limit of the inode table to 1 and checks if inode forgets
and resolve cause any problem with bit-rot xattrs (especially bad-file xattr).

Change-Id: I3a19f90384c980368152bb723e7263eab2bed6bd
BUG: 1252348
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11881
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Venky Shankar

rpc: fix concurrency bug in gf_authenticate

2015-07-29T14:14:41+00:00

The basic problem is that gf_authenticate abused global variables to
pass info through dict_foreach.  This is not thread-safe, but it wasn't
affecting most people until multi-threaded epoll came along.  Now, if
two threads get into this code at the same time - and there's nothing to
prevent it - one of them could free one of the dicts involved while the
other is still using it.

The fix is to pass this same information using a temporary structure
instead of globals.  This makes the code smaller and more efficient too.

Cherry picked from commit 8f04ec33bc86aa464a5f8b77f9d64e5608cb6f1b:
> Change-Id: I72cccc440bb40d5f7ff695250dd014762c7efb73
> BUG: 1247765
> Signed-off-by: Jeff Darcy 
> Reviewed-on: http://review.gluster.org/11780
> Tested-by: NetBSD Build System 
> Reviewed-by: Niels de Vos 
> Tested-by: Gluster Build System 
> Reviewed-by: Raghavendra G 

BUG: 1247850
Change-Id: I151dad436b859c64985421394f3dea572723c2aa
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/11785
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy

rpc,server,glusterd: Init transport list for accepted transport

2015-07-26T17:36:39+00:00

GlusterD or a brick would crash when encrypted transport was enabled and
an unencrypted client tried to connect to them. The crash occured when
GlusterD/server tried to remove the transport from their xprt_list due
to a DISCONNECT event. But as the client transport's list head wasn't
inited, the process would crash when list_del was performed.

Initing the client transports list head during acceptence, prevents this
crash.

Also, an extra check has been added to the GlusterD and Server
notification handlers for client DISCONNECT events. The handlers will
now first check if the client transport is a member of any list.
GlusterD and Server DISCONNECT event handlers could be called without
the ACCEPT handler, which adds the transport to the list, being called.
This situation also occurs when an unencrypted client tries to establish
a connection with an encrypted server.

Change-Id: Icc24a08d60e978aaa1d3322e0cbed680dcbda2b4
BUG: 1246809
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.org/11692
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G 
(cherry picked from commit a909ccfa1b4cbf656c4608ef2124347851c492cb)
Reviewed-on: http://review.gluster.org/11762

protocol/server: use different dict for resolving

2015-07-23T06:46:16+00:00

                 Backport of http://review.gluster.org/11661

protocol/server has to resolve the inode before continuing with any fop coming
from the clients. For resolving it, server xlator was using the same dict
associated with the fop. It causes problems in some situations.

If a directory's inode was forgotten because of lru limit being exceeded, then
when a create fop comes for an entry within that directory, server tries to
resolve it. But since the parent directory's inode is not found in the inode
table, it tries to do a hard resolve by doing a lookup on the parent gfid.

If any xlator below server wants to get some extended attributes whenever
lookup comes, then they set the new keys in the same dict that came along with
the create fop. Now, the lookup of the parent succeeds and the create fop
proceeds with the same dict (with extra keys present). posix xlaror creates
those xattrs that are present in the dict. Thus the xattrs which were not to
be present by default are also set as part of create. (Ex: bit-rot related
xattrs such as bad-file, version and sign xattrs)

Change-Id: I62b0b012b0af3c92df6fced61f87dd0b6b015d4c
BUG: 1244100
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11703
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

protocol/server: Add null check to gf_client_put

2015-07-09T10:10:49+00:00

Change-Id: I8bab3cd7387f89743e15e7569f0bc83a7df3c754
BUG: 1240603
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/11550
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11562
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

protocol/server: Correctly reconfigure auth.ssl-allow

2015-07-06T07:14:22+00:00

  Backport of https://review.gluster.org/11487

auth.ssl-allow wasn't being handled during reconfigure. This prevented
the ssl-allow list from being live reloaded.

Change-Id: If3435793a5684881b012de77cb254b1847b37810
BUG: 1238073
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.org/11492
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

protocol/server: fail setvolume if any of xlators is not initialized yet

2015-07-02T11:14:09+00:00

We can only start recieving fops only when all xlators in graph are
initialized.

Change-Id: Id79100bab5878bb2518ed133c1118554fbb35229
BUG: 1214169
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/11504
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System