Ambrogio wrote: >>>> Access rule are based on uid used on client at the mount time. >>>> If you use root on client (for example) to mount an export, tipically >>>> you can't access. Tim: >>> That's never been my experience. Firstly, normally only the root use >>> can mount something. Secondly, when mounting a Linux file system over >>> NFS, the original ownership is maintained, but numerically: User 500 >>> remote is treated as user 500 local, so you better make sure that >>> usernames and user IDs match on both sides of the connection. Ambrogio: > It is that I sayd. > For first, mount command is available also at user level. While you *can* make things user-mountable, it doesn't also mean that root mountable things will only be available to the root user. That sort of behaviour depends on the mount. I would go as far as to say that for things like NFS mounts, it's NOT typical to mount them as a user, and it's NOT typical that users can't access root user mounted mounts. > The user level is threated everytime numerically. > When you use ls -la and see a user insted of a number is only because ls > make a conversion, but on ACL we ave numbers. ls -lan would show numerical mounts (n option does that). > So, when you mount a NFS export into a linux machine and use ls -la you > are on a client, so ls convert numbers using local passwd and groups. Typically, with NFS, user 500 has to be user 500 on both machines, and so on. It doesn't matter if they use the same names on both sides, but that helps to make things coherent. If I am user 500, username Tim on one box, and export /home to another, I really also want to be user 500, on the second box. Then, I can access my files on both PCs. And, that mount is handled by root. All that's done with just two entries on each machine (NFS must be running, already). Server's /etc/export file: /home *.localdomain(rw,sync) This exports part of the file system to my LAN, the /home partition, and each user within that file system's home directories get exported as-is (Tim's files are Tim's elsewhere, johndoe's files are his elsewhere, and so on). Client's /etc/fstab file: server.localdomain:/home /mnt/server/home nfs auto,intr,noexec,nodev This mounts the export on a client machine. Root is doing the mount, but because the individual directories are owned by other people, and NFS understands ownership, ownership is maintained on both sides, so long as you set up the client machines with the same user IDs on both sides. I seem to recall reading that it is possible to map user IDs between different systems using NFS (e.g. on server Tim is 500, but Tim is 632 on a client, and 2349 on another client). But not seen anything detailing how. It's certainly possible doing that with Samba, but I find Samba to be just bloody awful in other ways (slow, messy getting Samba to work as if it were Linux, with proper Linux permissions, etc.). Mikkel L. Ellertson: >> Also, local root is normally mapped to user nobody on the remote >> system unless the no_root_squash option in used. "man exports" for >> more information. Ambrogio: > True... > normally root is squashed to very very non-priviledged user. And maybe > that on remote filesystem this special user are authorized to make > NOTHING. > So the result is access denied or something else. Only if the root user on a client tries to access files over on the server as if it was still the root. It'll only get treated as the root user locally. This stops someone who manages to exploit a client box (which is easy enough) from exploiting a remote box without putting a lot more effort into it. Users can access their own remote files the same as they can their own local files. I think you need to provide configuration examples, as well as examples of exactly what it is that you're trying to do. I suspect that you're expecting a local root user, or process running as root, to have access to files over the network. -- (Currently running FC4, occasionally trying FC5.) Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
