[ale] root_squash on backup server

Wed Oct 2 15:15:43 EDT 2013

I don't think that will work. Ownership is defined by what the server
thinks. So chown must use uid known by NFS server. If local uid is not
allowed at the server to chown to new uid that will fail.
Best route may be to create Amanda user with uid they use for storage.
On Oct 2, 2013 9:29 AM, "John Heim" <john at johnheim.net> wrote:

>
> I don't think I'm going to be able to get the other department to create a
> user for me. If I get them to set no_root_squash, I figured I could change
> the ownership by just setting the uid and gid to whatever I need it to be.
> I am not entirely sure you can change the ownership of files on an NFS
> share to that of users not on the remote server but I would think so.  I
> know it owrks the other way to a degree. If you mount a share that has
> files owned by users who are not on your system, it just identifies them by
> uid and gid. So if you do an 'ls -l', you see the uid and gid numbers there
> instead of the owner and group names.
>
> I know you can change ownership of a file that is on your own system by
> giving uid and gid, "chown 34:97 /home/john/bogus.txt". But I don't know
> for sure if that would work  over nfs. Well, actually, I'm thinking it
> should work to say, "chown amadmin:amadmin /bigdisk/vtapes/slot01" where
> the nfs share is mounted on /bigdisk because. amadmin is a recognized
> user/group on my system. If you do an 'ls -l' on the nfs server, it would
> show just numbers. (I think.)
>
> On 10/01/13 17:34, Jim Kinney wrote:
>
>> Hi John,
>>
>> You need root_squash on AND an amanda user with a matching UID/GID
>>  that owns the nfs share. That way amanda can read and write and root
>> access is no needed.
>>
>> It may be required to run idmapd to translate between nfs-server:amanda
>> and
>> backup-system:amanda if the GIDs can't be made to match.
>>
>> If the network uses LDAP, then just create the amanda user in LDAP and
>> should just work with root_squash on.
>>
>> The only headache is if at some point a low-level process that must run
>> as root also needs to access the backup space. It just won't work unless
>> you can copy files as amanda to another place as root. I got hit with this
>> using bacula and a remote nfs share with root_squash on and a need to run
>> low-level btape commands. it just wouldn't work. Root user was totally
>> barred from accessing the space.
>>
>>
>> On Tue, Oct 1, 2013 at 5:38 PM, John Heim <john at johnheim.net <mailto:
>> john at johnheim.net>> wrote:
>>
>>     My department got some space on a file server at another
>>     department. I can access it via an NFS mount. BBut I guess the
>>     root_squash option is set for the share because all the files I
>>     create are owned by nobody:root and I can't change the ownership.
>>     I want to use this space for amanda virtual tapes. Amanda doesn't
>>     want to run as user root.
>>
>>     So I'm thinking of asking the other department to turn off
>>     root_squash (set no_root_squash option for the share). But I don't
>>     want to look like a dope so I want to make sure I'm right about
>>     one thing ... It doesn't make my data any less secure, right?
>>     Here's my reasoning:
>>
>>     I can create files only as nobody:root anyway. The share is
>>     restricted by IP to just one machine. But if somebody gets past
>>     that (by spoofing the IP address or whatever) and mounts the
>>     share, they'd have the same access as I do when I'm using the
>>     share legitimately. That is true regardless of whether the
>>     root_squash or no_root_squash option is set.
>>
>>     If there were other users besides root creating files on the share
>>     it would be different. You don't want  john getting access to
>>     mary's files by just becoming root on his own machine. John could
>>     plug his laptop into the network, su to root, mount mary's home
>>     directory, and read her files. The root_squash option prevents
>>     that but it doesn't apply in the case of a backup server, right?
>>     If somebody gets past the IP restriction, they'd ahve the same
>>     access regardless of whether  whether root is squashed. (I think.)
>>
>>
>>
>>     I think I'm going to have to figure out how to encrypt  data
>>     written to a amanda virtual tape. But that's a question for the
>>     amanda list.
>>
>>     ______________________________**_________________
>>     Ale mailing list
>>     Ale at ale.org <mailto:Ale at ale.org>
>>     http://mail.ale.org/mailman/**listinfo/ale<http://mail.ale.org/mailman/listinfo/ale>
>>     See JOBS, ANNOUNCE and SCHOOLS lists at
>>     http://mail.ale.org/mailman/**listinfo<http://mail.ale.org/mailman/listinfo>
>>
>>
>>
>>
>> --
>> --
>> James P. Kinney III
>> ////
>> ////Every time you stop a school, you will have to build a jail. What you
>> gain at one end you lose at the other. It's like feeding a dog on his own
>> tail. It won't fatten the dog.
>> - Speech 11/23/1900 Mark Twain
>> ////
>> http://heretothereideas.**blogspot.com/<http://heretothereideas.blogspot.com/>
>> ////
>>
>>
>> ______________________________**_________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/**listinfo/ale<http://mail.ale.org/mailman/listinfo/ale>
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/**listinfo<http://mail.ale.org/mailman/listinfo>
>>
>
> ______________________________**_________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/**listinfo/ale<http://mail.ale.org/mailman/listinfo/ale>
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/**listinfo<http://mail.ale.org/mailman/listinfo>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20131002/cefb8afe/attachment-0001.html>