Manual Pages
Table of Contents
sectrace - manages permission tracing filters
sectrace add [-ip <ipaddr>] [-ntuser <nt username>
-unixuser <uid/unix username>] [-path <path>] [-a]
sectrace delete { [<index>] | all }
sectrace show [ <index> | all ]
sectrace print-status <status>
sectrace help <command>
When the filer determines that a user does not have permission
to perform a specific operation, it usually
returns a general Access denied error to the client
request. There are a wide variety of reasons why the user
might not have permission to do something which may have
nothing to do with the security in place on the file system,
often making it difficult to determine the source of
the error.
Using the sectrace command, administrators can generate
filters that track these requests and report the specific
reason why it was refused. The requests can be filtered by
any combination of IP address, user and path prefix. If
any filter matches an incoming request, the results will
be printed to the console.
Additionally, there may be instances where a user is
granted access when it seems like they should not be. The
sectrace command allows you to create filters that track
these events as well, and you can print the full list of
decisions that were made which allowed that request to
proceed.
When active, these filters may have a minor impact on performance.
They are designed to be used temporarily in
order to help diagnose specific permission problems, and
should not be used for any other purpose.
NOTE: sectrace functionality is currently limited to
requests from the CIFS protocol. Support for additional
protocols may be added in future releases
-
add
- Adds a permission tracing filter and
starts tracing requests that meet all
the criteria specified in this filter.
It also returns the index of the filter,
which can be used to reference
the filter in other sectrace sub-commands.
Currently a maximum of 10 filters
can be set per vFiler(tm).
-
-ip <ipaddr>
- Specify the IP Address of a client.
The filter would match only if the
request is received from this client.
-
-ntuser <nt username>
-
Specify the NT(tm) user name. The filter
would match only if the request is
received with this user. The <NT username>
can be of the form DOMAIN\USER
or USER. This option cannot be used if
-unixuser is provided.
-
-unixuser <uid/unix username>
-
Specify the UNIX(R) user name (uid).
The filter would match only if the
request is received with this user
name credential. This option cannot be
used if -ntuser is provided.
-
-path <path>
- Specify a path prefix. The filter
would match only if the request is
received for a file or directory with
this path prefix.
-
-a
- Specify whether to trace ALLOW
requests as well, along with DENY
requests that are traced by default.
-
delete
- Deletes one or all permission tracing
filters based on the options provided.
If a filter index is specified, the
filter bearing this index is deleted.
If all is specified, all permission
tracing filters added in the
vFiler(tm) are deleted.
print-status <status>
This takes in the <status> code logged
corresponding to a request and provides
detailed information about the
reason for DENY or ALLOW of a request.
The <status> code is marked with a
Status: tag in the logged message.
-
show
- This displays the permission tracing
filters added in a vFiler(tm). If the
index is specified, the filter bearing
this index is displayed. If all is
specified or no option is provided,
all filters are displayed.
-
help <command>
- This provides a brief reference on
command usage.
Setting a simple deny filter for requests from a specific
client:
sectrace add -ip 192.168.10.23
Setting a filter for both ALLOW and DENY requests for a
UNIX user with login foo accessing home directory under
/vol/vol0/home4 :
sectrace add -unixuser foo -path /vol/vol0/home4 -a
Displaying filter bearing index 5 :
sectrace show 5
If a very generic filter is set which results in a lot of
requests being traced and logged:
Some events might get dropped and not get logged.
The filer console might get spammed with log
events.
It is recommended to add criteria to make the filters
more specific. e.g.: limiting the filter match criteria to
a specific user or IP Address.
Table of Contents