Re: aname_to_locaname + some offtopic

Thanks Jeffrey,

I wish comments like your message would be present in the man pages
for the API.

On Wed, Oct 12, 2011 at 02:09:24PM -0400, Jeffrey Hutzelman wrote:
> > > C) Let heimdal do A.  But, offer a 'reference design' for B1 that OS 
> > > implementers can use for guidance.
> > 
> > Ouch. The bug is "the belief that this can be done"
> > ("once and for all services and setups"?).
> 
> Well, no.  The bug is using this fairly legacy code far beyond its
> original intended scope, which was for inferring userids for Kerberos

Agreed. Actually, "OS implementers" aims at a wide/undefined scope
of "OS", that's what I reacted to.

> Also note that it's not intended for random other services that provide

It is unfortunately hardly evident (say, from the man page) what the
intended scope was.  :(

<OFFTOPIC for Kerberos, ontopic for distributed systems>

> > The custom of synchronization of unix uids/gids over a campus existed
> > only for nfs's sake. There is actually no reason to have it this way
> > as soon as you throw out sec=sys.
> 
> Actually, that's only mostly true.  It turns out that things work a bit
> better if the UIDs visible in the filesystem match those in the client's
> database.  For example, this affects whether 'ls' returns correct

NFSv4 helps it to look better as long as there are corresponding
_names_ so the synchronization of the numbers is not necessary.

The trouble is that this is impossible for any file system which crosses
borders of administration domains. This is a design limitation in Unix
and a corresponding misfeature in ls.

Users are going to access "foreign" resources anyway (by virtue of AFS
and Coda if not otherwise) so it's a matter of education. We tell them:
"ls -l" is broken by design, can not be fixed :(

The display of access mode bits is anyway broken on modern systems as
mode bits can not express the acl semantics. The semantics of an "owner"
and "group" is also different given acls (these properties make sense
together with Unix mode bits, not otherwise). In other words, it is
a mess no matter what.

> results, and whether it is reasonable for a client to respect setugid
> bits on files in a remote filesystem.  Also, there are unfortunately a

It might be sufficient to synchronize the _names_ of the concerned
accounts/groups. That said, "remote setugid" induces other nasty
security issues and is far from recommendable (and never the only
possible solution).

> number of things which incorrectly guess whether a filesystem operation
> will be allowed by directly examining the mode bits and UID of a file.
> Most recently, I discovered that current Ubuntu kernels contain such a
> check, which prevents a user creating hardlinks to his own files if the
> UIDs don't match.

That's a shame and quite stupid if being applied to remote file systems,
such decisions belong on the server.

Anyway it is not a practical problem inside a single administration
unit - a file system like NFSv4 translates the "ownership" to its client
equivalent, as soon as there is a suitable account _name_ on the NFS client.

</OFFTOPIC>

Regards,
Rune