Bug 151778 – [PATCH] More advanced suidctl Portage feature

• Product: Portage Development
• Status: RESOLVED DUPLICATE

[Description email_deleted_GqKU 2006-10-17 20:52:57 UTC]

I'm using portage-2.1.1 (I hope something similar has not been already coded in the latests versions :)), and the suidctl.conf file only allow for the file path to be checked, to decide if `emerge` will strip the SetId permissions or not.

To enhance security (though it probably will seem a bit overkill to some people), I propose to add checks on package category/name (as a filename might be used by multiple packages -well, there is "collision-protect", so once a known package has installed the file, there should not be any problem, but it might still be useful), file user, group, and original permissions (as they might be changed by upstream or maintainers, which might lead the user to reconsider his choice about SetId permissions for the file), and to permit to configure the exact permissions to set to the file, if the original permissions should not be kept (the possibility the configure the user and group might also be added, for full customization -though it might then be a modification which would probably qualify as an ebuild enhancement).

I will attach a patch to the "misc-functions.sh" file, and a default configuration file, with comments...

The patch and configuration file is not compatible with the current suidctl implementation, but compatibility should be easy to add, if needed (otherwise, an ewarn might be displayed, if the older version of the feature is detected -in "FEATURES", or as the "/etc/portage/suidctl.conf" file, to inform the user of the changes...).


(Note I do not have much more time to spent on this report, so I hope someone will be able to make the possible necessary modifications, depending on comments :))

[Comment 1 email_deleted_GqKU 2006-10-17 20:58:43 UTC]

Created attachment 99915 [details, diff]
Patch for an advanced version of the suidctl Portage feature

Note that the modifications have been only lightly tested... and you might want to shorten some variable names, if you do not like long names :) (and maybe reformat some other things, if you do not like this style and/or prefer to be consistent -which I understand).

As said in the original comment, this change, as implemented by this patch, is not compatible with current implementation of the suidctl features (though a new name has been used for the feature, so a simple warning might do -well, you might also add some compatibility).

[Comment 2 email_deleted_GqKU 2006-10-17 21:02:39 UTC]

Created attachment 99916 [details]
Default configuration file (with comments) for the feature

As said, the file (which does not have the same name as the previous one), does not have the same format.

The format being more complex, the default configuration file should most probably be included by default, either as "/etc/portage/setid-control.conf", or as something like "/usr/share/portage/setid-control.conf.default" (which is used in the posted patch, and copied to "/etc/portage/setid-control.conf", if the file is not present).

[Comment 3 Marius Mauch (RETIRED) 2007-01-11 07:33:42 UTC]

I'd more inclined to outsource this features as a bashrc hook. suidctl doesn't seem widely used, so I'm not much for adding extensive patches to it (even if it's  mostly comments).

Solar: IIRC you added suidctl originally (or was that sfperms?), so what do you think about this?

[Comment 4 solar (RETIRED) 2007-06-06 01:42:40 UTC]

(In reply to comment #3)
> I'd more inclined to outsource this features as a bashrc hook. suidctl doesn't
> seem widely used, so I'm not much for adding extensive patches to it (even if
> it's  mostly comments).
> 
> Solar: IIRC you added suidctl originally (or was that sfperms?), so what do you think about this?

both.. but to be honest I'm in favor of dropping suidctl all together. 
Nick merged it not the way I had quite intended.

[Comment 5 Zac Medico 2011-12-27 01:30:02 UTC]

*** This bug has been marked as a duplicate of bug 396153 ***