Create a depot with non-root user

[Vibhor Kumar Agarwal]

Hi,

I am creating a depot with non-root user.
Giving the "run_as_superuser=false" with swpackage command starts the process successfully.

I want the files to have the permissions of the user with which the swpackage command is being run but the files should get deployed as permissions of root. This is what is troubling me.

If the permissions are of the calling user, it gets deployed with the same permissions.
The "file_permissions -o bin -g bin -m 555" tag doesn't take only "owner" & "group", it requires "mode" as well. This gives the same permissions to all files.

How can i create the depot with a non-root user will file permissions on getting deployed as root (having calling user permissions in the package creation directory)?
Thanks

[F Verschuren]

If this is poseble there is a leak in the swinstall, to do this you can uses sudo to give the user (partitual) root acces to run the swinstall,

If a normal user is able to create a depot whit root files, and can install it the user can get root privilages (and if that works there is a security leak in swinstall....)

how to implement sudo Just reares for sudo ore sudoers on the forum...

[Vibhor Kumar Agarwal]

Talking about creation of packages and not installing.

User can create packages with a non-root user, but the installation requires him to be root.

[Bob E Campbell]

This is Unix... anything is possible!

Take a look at the swacl(1m) man page. It allows fine-grained control over SD-UX operations. The catch is well stated in that page:

Some operations allowed by ACLs are run as local superuser. Because files are loaded and scripts are run as superuser, granting a user write permission on a root filesystem or insert permission on a host effectively gives that user superuser privileges.


So you *can* allow users installation priviledges, but anyone that can install software should be considered to have full root access.

[Vibhor Kumar Agarwal]

Probably you misunderstood my question.

I only want to create the depot with non-root user.

Please go through my first post, the problem is putting the right permissions in the depot files.

[Bob E Campbell]

If you look at the Examples section of the swacl(1M) man page you will see several items of interest. In particular:

To allow user allen to create, register, and manage all new depots and roots on the local system:

swacl -l host -M user:allen:a
swacl -l global_soc_template -M user:allen:a
swacl -l global_product_template -M user:allen:a

To allow user allen to fully manage my_depot, which already exists:

swacl -l depot -M user:allen:a @ /my_depot
swacl -l product_template -M user:allen:a @ /my_depot
swacl -l product -M user:allen:a \* @ /my_depot

[Vibhor Kumar Agarwal]

Went through swacl man page. Couldn't find the thing i am looking for.

Here is what i want:
Have a couple of files named a & b with permissions of user x. I want them to get deployed when root installs the depot as "root".
file_permissions attribute is not helping me because it can't take the owner & group argument alone, it require mode as well. My files have different modes and don't want to specify that tag for every file.

[Dennis Handly]

>Have a couple of files named a & b with permissions of user x. I want them to get deployed when root installs the depot as "root".

You can leave out the -m mode and use the file specification for your few root files.
All other files should have the proper modes (and owners if possible) before you use swpackage.

[Bob E Campbell]

Oh! This is a PSF question. That man page is swpackage(4) (use command "man 4 swpackage").

In the PSF you can specify attributes on a per file/directory basis. For example:

file -m 0555 -o bin -g bin /tmp /opt/swa

If you post your PSF (or an abstract) we could propose specific changes.

[Vibhor Kumar Agarwal]

> You can leave out the -m mode and use the file specification for your few root files.

That's what exactly what i want and is not happening.

Sample psf file (of the fileset tag):
directory Test=/opt/Test
file *

Tried giving
file_permissions -o bin -g bin
but it gives an error & requires the "-m" tag as well, like below (but this disturbs my file permissions)
file_permissions -o bin -g bin -m 555

If i can somehow give "file_permissions -o bin -g bin", my problem is solved.
Options ?

[Dennis Handly]

>Tried giving file_permissions -o bin -g bin
but it gives an error & requires the "-m" tag as well

I don't have any problems leaving out -m on 11.11, 11.23 or 11.31. You can also use "-u 222" as the documentation suggests.

>If I can somehow give "file_permissions -o bin -g bin", my problem is solved.

I have no problems doing that. What error do you get?

[Vibhor Kumar Agarwal]

Here is snippet of psf:

fileset
directory Test=/opt/Test
file_permissions -o root -g sys
file *

Error:
WARNING: Invalid value defined for the keyword "file_permissions", at
line 23. Valid values for this keyword are:

[-m mode|-u umask ] [-o [owner[,]][uid]] [-g [group[,]][gid]]

where each component of the value defines a default permission
for files in the fileset.


If I add the "-m" tag in the file_permissions, it creates without any error.
My system is HPIA 11.31

Putting the "-u" tag also will disturb the base permissions of my file

[Dennis Handly · Accepted solution]

>My system is HPIA 11.31

Do you have any SD patches? I don't get that error. I'll check mine.

>[-m mode|-u umask ] [-o [owner[,]][uid]] [-g [group[,]][gid]]

As I mentioned above, simply use "-u 222" instead of -m.

[Dennis Handly]

My version is: SW-DIST B.11.31.0803.317

[Vibhor Kumar Agarwal]

Give me a couple of days.
I'll get back on Monday.

[Vibhor Kumar Agarwal]

Thanks

Putting "-u 000" solved my purpose.
Giving "-u 222" was subtracting the permissions.

[Dennis Handly]

>Giving "-u 222" was subtracting the permissions.

Yes. You wanted files with write permission?

[Vibhor Kumar Agarwal]

I want the permissions as it is as they are present in the directory from which I am building the package.

[Dennis Handly]

>I want the permissions as it is as they are present in the directory

I was questioning why you would ever deliver a file that was writable?
These files, unless marked volatile and are in /etc or /var, should be treated as read only. And you may have swverify issues, if changed.

[Vibhor Kumar Agarwal]

A couple of files are script files which have to be run after the package has installed.
These scripts start the services.

Is there any other option rather than sending them as writable?

Could you give me some information about the volatile files, i am unaware of this.

[Dennis Handly]

>A couple of files are script files which have to be run after the package has installed.

Scripts have to be executable, not writable. And if they have to be run after, they should be configure control scripts.

>Is there any other option rather than sending them as writable?

Sending what as writable?

>Could you give me some information about the volatile files

You add -v to file attribute describing the file.

[Vibhor Kumar Agarwal]

Ooops,

I meant executable.
There are some files which have only read permission to root (r--,---,---) and many variants.

In such a case i will have to give different "-u" for each group of files.
Hence, i choose the "-u 000" option.

Is there any drawback in it?

[Dennis Handly]

>There are some files which have only read permission to root (r--,---,---) and many variants.
>In such a case I will have to give different "-u" for each group of files. Hence, I choose the "-u 000" option.

No need to use -u 000, you can use -u 222 to make sure all files are read only. It only removes any "w" permissions.

[Vibhor Kumar Agarwal]

Gotcha :-)

Thanks