The file pattern filter matches names, and the operations that read an item
evaluate it on the item itself. Three did not agree with that: a copy
evaluated it on the target only, a rename mapped every refusal to a
permission error and so discarded the deny policy configured on the filter,
and symlink creation honored the hide policy alone, letting the default one
through.
They now all evaluate the source and report the configured policy through
GetErrorForDeniedFile, as stat, download and delete already do, so the same
filter gives the same answer whichever operation reaches a name. The target
keeps reporting a permission error: it is a path being written, not an item
being read. isRenamePermitted returns an error and is renamed accordingly;
the recursive walk still reports a permission error, because the entries it
walks are the contents of the directory being renamed and a hidden one among
them must not make that directory look missing.
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
The read goes through a regular download transfer, so it honors the data
transfer quota and the bandwidth limit, it counts towards the transfer limits,
it is listed among the active transfers and can be monitored and aborted, and
it triggers the pre-download and download events.
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
Computing a digest reads the whole file, so the hash commands now require the
download permission on the parent directory, the same check a download
performs. They previously accepted the list permission: accounts granted list
without download now get a permission denied error.
Reported-by: @cyny666
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
With query_userinfo enabled, the UserInfo endpoint is queried after
authentication and the user claims are read from both sources. Claims
from the verified ID token take precedence on conflicts, empty values
do not override, and the UserInfo subject must match the ID token
subject. The option is validated at startup against the provider
metadata.
Reading the claims from the UserInfo endpoint was requested in #2265
and an implementation, enabled by default and with the opposite claim
precedence, was proposed in #2266.
Fixes#2265Closes#2266
Suggested-by: TEC <git@tecosaur.net>
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
The token manager Add now reports whether the entry was persisted and the
provider-backed manager logs the failure, so an invalidation that does not
happen leaves a trace instead of being dropped in silence.
The REST admin and user logout propagate the error and answer 500: the
response states that the token has been invalidated, so it must not be
sent while the token is still usable. invalidateToken also reports an
error for a request without a verified token, there is nothing to
invalidate in that case.
Invalidation that is a side effect of another operation stays best effort
and does not gate that operation's result: the password is already
changed, the request is already rejected, the pre-login token goes away
with the cookie. Those call sites rely on the token manager log.
The web logout paths keep clearing the login cookie and redirecting
instead of rendering an error page: the client is logged out locally
either way, and a failed store write only matters to someone who already
holds a copy of the token.
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
Invalidation was keyed on the exact token text, so an equivalent
Base64URL spelling of the same signed token did not match the stored
entry and kept working after a logout. The store is now keyed on the
"jti" claim, which is invariant across equivalent encodings of one token.
This is a correctness fix and not a privilege boundary: producing an
equivalent spelling requires already holding a valid signed token, it
grants no additional access, and the token remains usable only until its
own expiry, a bound it never exceeds.
Reported-by: Corban Villa (@corbanvilla)
Reported-by: Sohee Kim (@soh3e)
Reported-by: Austin Chu (@dderpym)
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
Nicola Murino