On Sun, 7 Aug 2016, Karl-Philipp Richter wrote:
> Hi,
> I'm authenticating for my OpenAFS with `kinit admin && aklog` as user
> `richter` and get read/write access to all my volumes. Yet, the
Presumably the 'admin' pts entry has pts ID 1?
> ownership is `daemon:richter` on all files which I can change with
> Linux' `chown` command. Strangely those changes are undone over the time
> and the ownership becomes `daemon:richter` again. I didn't observe the
> process of resetting and thus can't tell if they're reset all at once or
> over the time.How can I make my files permanently be owned by
> `richter:richter`?
The permissions that are stored in AFS (i.e., on the AFS fileserver)
generally reflect the pts ID, not the local user ID. So, with a token for
'admin', with pts ID 1, the owner ID of 1 gets stored on the fileserver.
When the cache manager reads the file back from the fileserver, it sees
the owner id 1 and reports that to the userland tools such as ls(1).
ls(1) does not know that it is in AFS and consults the local user database
as usual, seeing that user ID 1 is mapped to the user 'daemon', displaying
that to you. In AFS, it may be less confusing to use numeric IDs for the
ls(1) output.
With regard to the "resetting over time", I do not have as authoritative
an answer, but it seems consistent with your chown operations only being
reflected in a local cache (maybe even the linux VFS cache, not the AFS
cache), so when the local cache is invalidated the "bad" data is fetched
again from the server.
In general, the owner ID is not used in AFS, with the main exception being
that the owner of the root of a volume (i.e., what appears as the
mountpoint in the /afs namespace) has implicit 'a' permissions within that
volume, in the default fileserver configuration.
-Ben
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
