IRIX and Software

inst on (root) nfs fail to preserve set(uid|gid) permissions

Hello,

I've noticed something interesting, which gave me several hours of headache.

When inst is performed on a system with nfsroot, setuid/setgid permissions are not, by default, placed. As such, if one is to update, say, /sbin/su, which requires setuid bit set, if such binary is located on a nfsroot filesystem, the setuid bit will not be placed when inst will upgrade /sbin/su.

I haven't found a way to overcome this bug with inst, the proper alternative is to list all the files with setuid/setgid permission set and compare the results after an upgrade/install; but this doesn't account for new files.

Is there a better way to solve this? Please note, this happens *only* on nfsroot systems; I haven't tried on systems with partial nfs root, so I don't know the extend of the bug.

Cheers!

_________________
:Onyx2:
Have you checked the flags set on the system serving the filesystem being mounted as "/" on the client where you're running inst? You may already know there have long been options to allow the remote root user to be mapped to different UIDs, but I wonder if the serving system may have added more fine-grained controls. I can imagine that just as the serving system might have mounted the underlying filesystem with "-o noatime" -- it might have exported it with some new default like "nosetuid". And if it's Linux, I have no idea what SELinux might be doing...

Or of course, it could just be a bug in inst. I don't know how many IRIX systems would have been run in a traditional diskless configuration after the 90s...

_________________
Then? :IRIS3130: ... Now? :O3x02L: :A3504L: - :A3502L: :1600SW: +MLA :Fuel: :Octane2: :Octane: :Indigo2IMP: ... Other: DEC :BA213: :BA123: Sun , DG AViiON , NeXT :Cube:
smj wrote:
Have you checked the flags set on the system serving the filesystem being mounted as "/" on the client where you're running inst? You may already know there have long been options to allow the remote root user to be mapped to different UIDs, but I wonder if the serving system may have added more fine-grained controls. I can imagine that just as the serving system might have mounted the underlying filesystem with "-o noatime" -- it might have exported it with some new default like "nosetuid". And if it's Linux, I have no idea what SELinux might be doing...

Or of course, it could just be a bug in inst. I don't know how many IRIX systems would have been run in a traditional diskless configuration after the 90s...


I don't think this would be the problem, because I _can_ put the setuid/setgid bit manually (on the nfs client, on the exported filesystem). It's inst, which, when operating on nfs volumes can't; it probably expects xfs/efs by default. This is indeed a very interesting phenomena; which I don't believe to be tied to the nfs server or nfs client itself. It could be an inst "preference" which causes this of course, such as "confirm_nfs_installs" perhaps.

I run all my SGIs (at the exception of the Onyx2) diskless; although most of them were converted to nfs(root) AFTER installation of software + patches, which is why I had never observed this before.

Let me know what you think.

_________________
:Onyx2: