[apologies for top-posting - damn LookOut :-(] I don't like the sound of this. For example, we want to install Apache. It *needs* its own account for security reasons. But the account should not be created on a system that isn't running it, again for security reasons.
Catch 22 - we daren't create the account before the app is installed, but the installation doesn't create the account before it runs therefore permissions are lost. Is there any way we can spec it so alien has to retain ownership for system ids? That way the package can create the id as it installs without leaving a security hole of unnecessary user ids. I would be very chary of saying it should only preserve ids in a pre-defined list - what happens if my package runs lock daemons etc as system ids, but it's too small or new to have been assigned a user-id by LANANA? I'd be inclined to say that "any conversion utility must retain permissions, asking the user's permission to create a new account if necessary". -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 23 May 2001 16:27 To: [EMAIL PROTECTED] Subject: [Lsb-CommonPackaging] Re: rpm specification & alien If you have any input, then please respond to [EMAIL PROTECTED] Thanks, George Kraft IV [EMAIL PROTECTED] IBM Linux Technology Center FSG's Linux Standard Base ---------------------- Forwarded by George Kraft/Austin/IBM on 05/23/2001 10:26 AM --------------------------- Mark Johnson <[EMAIL PROTECTED]>@mcgarrett.adsl.duke.edu on 05/23/2001 09:04:01 AM Please respond to [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Chris Yeoh <[EMAIL PROTECTED]> Subject: Re: rpm specification & alien Chris Yeoh writes: > Whilst attempting to convert an RPM package to a deb package using > alien I noticed that alien appears to have problems with preserving > the ownership of files if the user accounts do not (yet) exist on the > system on which the conversion is done. ... > Do we need to add a note to the specification that requires that the > RPM packages only rely on the ownership of files being preserved if > those files are owned by user accounts required to exist by the LSB > spec? Chris' suggestion sounds both reasonable and sensible. A straightforward policy like this would also enable stronger enforcement of package file permissions, thereby making it more difficult to be sloppy about such things. Furthermore, a reduced set of allowable permissions might even simplify the packaging process. Cheers, Mark > Regards, > > Chris. > -- > [EMAIL PROTECTED] > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED] -- _____________________________________ Mark Johnson Senior Lecturing Fellow Department of Physics Duke University Durham, NC 27708-0305 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED] _______________________________________________ Lsb-taskforce1 mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/lsb-taskforce1 This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: London +44 (0)20 7351 5000, Hong Kong + 852 (0)2 121 2388 and New York +1 (0)212 647 0550.
