[split] why is my suggestions were consider incorrect.

[pingtoo]

Now that OP consider this problem solved. I would like to request to move from my this post onward to *Gentoo Chat* section if that is possible.
Admin Edit: Split from [SOLVED] ebuild failing to handle redirects as requested. Good suggestion, thanks. --pjp

I like to understand why is my suggestions were consider incorrect.

So it may appear to be permission problem but it is two different permission, first one is your own userID not able to write to a directory (/var/cache/distfiles) usually own by UID/GID "portage/portage". This can be fix by place your ID in to "portage" group.

This is the wrong solution.

I like to learn why is placing UserID into *portage* group is *wrong*? I believe it is documented in Gentoo handbook in *User administration* section suggest daily user to be place in *portage* group to *Be able to access portage restricted resources.*

Second one you use "sudo", however "root" does not have permission to write in to your project dir(/home/ari/Ari/coding/resources_/dinolay/app-office/sc-im), this can be fix by chmod 777 to /home/ari/Ari/coding/resources_/dinolay/app-office/sc-im.

Changing permissions to mode 777 is almost always the wrong solution. Please do not recommend this without an explanation of why it is appropriate.

I understand from security point of view making a directory permission open wide is not a good practice. However my suggestion is direct point for using *sudo* which change effect UID to *root* and therefor the directory must allow *root* to create new file in order for the sudo method to work. And without going through how the exact environment was setup, it would be much quicker to use a command to illustrate the setup to allow root write access. I would think for security concern using *sudo* to perform this task is inappropriate in the first place, would you agree?

Finally curious mind like to learn, since I was not explain will, Would someone care enough to help me understand what is appropriate way to answer when someone want to use a risky method (using sudo) in the place were risky method already executed but still encounter error and the solution to address the error.

[pjp]

I like to learn why is placing UserID into *portage* group is *wrong*? I believe it is documented in Gentoo handbook in *User administration* section suggest daily user to be place in *portage* group to *Be able to access portage restricted resources.*

I had intended ot make my above post prior to seeing this query of yours, but hopefully it is helpful. Hu may have other or additional reasons. I only add the above post as a starting point and why I stopped relying on being a member of the group. I obviously do not "speak" for Hu.

I understand from security point of view making a directory permission open wide is not a good practice. However my suggestion is direct point for using *sudo* which change effect UID to *root* and therefor the directory must allow *root* to create new file in order for the sudo method to work. And without going through how the exact environment was setup, it would be much quicker to use a command to illustrate the setup to allow root write access. I would think for security concern using *sudo* to perform this task is inappropriate in the first place, would you agree?

I almost replied to that suggestion before Hu did. You claim to know that for security reasons it is bad practice to suggest using permissions 777, yet you did anyway. I don't understand your point about sudo, and how that somehow justifies using 777? If root cannot access a file, I'd like to know the standard permissions that prevent root from manipulation of said file. If root cannot, then it would seem to indicate standard permissions are not the problem. A quick demonstration on a file not owned by root with no permissions, and root has no problems manipulating it:

Code: Select all

$ whoami
root
$ touch /var/tmp/portage/foo
$ chown portage.portage /var/tmp/portage/foo 
$ chmod 000 /var/tmp/portage/foo 
$ ls -l /var/tmp/portage/foo 
---------- 1 portage portage 0 Sep 12 14:52 /var/tmp/portage/foo
$ echo "testing" >> /var/tmp/portage/foo 
$ cat /var/tmp/portage/foo 
testing
$ rm /var/tmp/portage/foo 
$ ls -l /var/tmp/portage/foo 
ls: cannot access '/var/tmp/portage/foo': No such file or directory

An unrelated situation might be using sudo to access a privileged file and the user calling sudo trying to write output to a privileged area thinking that sudo will allow it, but sudo does not. Example where running a program, the user wants the output to be saved to the root user's home directory:

Code: Select all

$ sudo program > /root/datafile

This doesn't work because the output is redirected by the user calling sudo, not sudo itself. There's a way around that, but I never remember it and have to search for it.

Finally curious mind like to learn, since I was not explain will, Would someone care enough to help me understand what is appropriate way to answer when someone want to use a risky method (using sudo) in the place were risky method already executed but still encounter error and the solution to address the error.

Again, i don't understand your point about sudo being risky in this situation, nor do I understand why that supposedly makes it OK to recommend using 777 permissions without a warning and explanation. To the general question you're asking about how to make the suggestion, I would think explaining why you are making the suggestion and the risks it introduces would be useful. Also why you think the risky recommendation will help, or what it will demonstrate. Also when it should be undone, or why i should remain after the test.

[Hu]

I like to learn why is placing UserID into *portage* group is *wrong*?

As briefly described by my post from last year, which pjp cited and quoted, there are Portage restricted resources which can be written by anyone in the Portage group. Some such resources could, if modified, cause problems. For example:

• /var/lib/portage/preserved_libs_registry - mode 660, root:portage. If truncated, Portage would not handle previously preserved shared libraries as expected.
• /var/log/emerge.log - a long running log of everything you have ever emerged. Losing it would not hurt Portage, but some people find its content to be useful, so if lost, it would need to be restored from a backup.

I believe it is documented in Gentoo handbook in *User administration* section suggest daily user to be place in *portage* group to *Be able to access portage restricted resources.*

Do you have a citation for this?

Changing permissions to mode 777 is almost always the wrong solution. Please do not recommend this without an explanation of why it is appropriate.

I understand from security point of view making a directory permission open wide is not a good practice. However my suggestion is direct point for using *sudo* which change effect UID to *root* and therefor the directory must allow *root* to create new file in order for the sudo method to work. And without going through how the exact environment was setup, it would be much quicker to use a command to illustrate the setup to allow root write access. I would think for security concern using *sudo* to perform this task is inappropriate in the first place, would you agree?

The user must run the command with uid root, either from a root shell or from a sudo call. I don't see how one is worse than the other here. Popular sudo configurations are less secure than I like, but that is outside the scope of the problem.

As pjp described, any permissions mechanism that can block root will likely block root whether the permissions are strict or are world-everything (0777). I suspect that in this case, the failing process wasn't really running as root, and so was falling victim to restrictive search permissions on a parent directory.

Finally curious mind like to learn, since I was not explain will, Would someone care enough to help me understand what is appropriate way to answer when someone want to use a risky method (using sudo) in the place were risky method already executed but still encounter error and the solution to address the error.

The solution is to understand the error, and then perform a targeted fix for the error, rather than switch to an even more risky method. Opening the permissions does nothing to understand the error, and so does nothing to explain whether that is a good approach. However dangerous sudo may be, it at least has the small virtue that it elevates the named process, so when the process exits, the elevated risk ends (assuming the process did not make filesystem changes that perpetuate the risk, such as installing an unrestricted setuid binary). Changing filesystem permissions is permanent until revoked by the owner, and users could easily forget to revoke the change if the revocation is not done immediately.

[pingtoo]

@pjp, Greatly appropriate you help to start this conversation.

I like to learn why is placing UserID into *portage* group is *wrong*? I believe it is documented in Gentoo handbook in *User administration* section suggest daily user to be place in *portage* group to *Be able to access portage restricted resources.*

I had intended ot make my above post prior to seeing this query of yours, but hopefully it is helpful. Hu may have other or additional reasons. I only add the above post as a starting point and why I stopped relying on being a member of the group. I obviously do not "speak" for Hu.

Thank you very much for the explain. I have never encounter user actions such as your described therefor never thought of someone will mistakenly hurt them self this way.

I understand from security point of view making a directory permission open wide is not a good practice. However my suggestion is direct point for using *sudo* which change effect UID to *root* and therefor the directory must allow *root* to create new file in order for the sudo method to work. And without going through how the exact environment was setup, it would be much quicker to use a command to illustrate the setup to allow root write access. I would think for security concern using *sudo* to perform this task is inappropriate in the first place, would you agree?

I almost replied to that suggestion before Hu did. You claim to know that for security reasons it is bad practice to suggest using permissions 777, yet you did anyway. I don't understand your point about sudo, and how that somehow justifies using 777? If root cannot access a file, I'd like to know the standard permissions that prevent root from manipulation of said file. If root cannot, then it would seem to indicate standard permissions are not the problem. A quick demonstration on a file not owned by root with no permissions, and root has no problems manipulating it:

Code: Select all

$ whoami
root
$ touch /var/tmp/portage/foo
$ chown portage.portage /var/tmp/portage/foo 
$ chmod 000 /var/tmp/portage/foo 
$ ls -l /var/tmp/portage/foo 
---------- 1 portage portage 0 Sep 12 14:52 /var/tmp/portage/foo
$ echo "testing" >> /var/tmp/portage/foo 
$ cat /var/tmp/portage/foo 
testing
$ rm /var/tmp/portage/foo 
$ ls -l /var/tmp/portage/foo 
ls: cannot access '/var/tmp/portage/foo': No such file or directory

An unrelated situation might be using sudo to acqcess a privileged file and the user calling sudo trying to write output to a privileged area thinking that sudo will allow it, but sudo does not. Example where running a program, the user wants the output to be saved to the root user's home directory:

Code: Select all

$ sudo program > /root/datafile

This doesn't work because the output is redirected by the user calling sudo, not sudo itself. There's a way around that, but I never remember it and have to search for it.

Finally curious mind like to learn, since I was not explain will, Would someone care enough to help me understand what is appropriate way to answer when someone want to use a risky method (using sudo) in the place were risky method already executed but still encounter error and the solution to address the error.

Again, i don't understand your point about sudo being risky in this situation, nor do I understand why that supposedly makes it OK to recommend using 777 permissions without a warning and explanation. To the general question you're asking about how to make the suggestion, I would think explaining why you are making the suggestion and the risks it introduces would be useful. Also why you think the risky recommendation will help, or what it will demonstrate. Also when it should be undone, or why i should remain after the test.

The reasons I claim I understand it is security concern and yet use chmod 777 dir is because I assume the user who call sudo already understand the security implication. And I just want to use chmod 777 dir to point out it will solve the user encountered problem. in part because the user executed two different procedures and yet got same permission error, so it make it looks like both procedures are meaningless and not address the problem. my point of make chmod 777 dir is to point out the second procedure is a different error. I believe using sudo to run any commands is inherently risky, you maybe aware that sodo before execute the given command will prompt a messages indicate you are about to execute something sysadmin consider risk procedure. That is the reason I call using sudo are risky.

Thank you for taking time to hear my side of story.

[pjp]

sudo seems to remove risk compared with using root directly, so I still don't understand that point.

Using permissions 777 adds risk compared with using a more restricted mode.


While looking for solutions to problems, I've seen recommendations to set 777 on files or directories accessible by web server software. That seems like a solution worse than the original problem. In my opinion, there are few if any situations that can justify such an approach. Maybe an extremely isolated test environment, but even then it seems questionable.

The human factor seems to tend toward the easy path which may make such approaches more risky than they first appear.

[gtwrek]

I believe it is documented in Gentoo handbook in *User administration* section suggest daily user to be place in *portage* group to *Be able to access portage restricted resources.*

Do you have a citation for this?

It's implied here:
https://wiki.gentoo.org/wiki/Handbook:A ... _daily_use

I've done such for my systems. I never really dug under the covers much to see what being a member of group "portage" gives me (without needing a sudo). But I do know I can eselect news read (and mark the item as read) without sudo.
I'd assumed the portage "group" was designed for such things. i.e. some portage tasks need some elevated permissions but not full root.

[pingtoo]

I like to learn why is placing UserID into *portage* group is *wrong*?

As briefly described by my post from last year, which pjp cited and quoted, there are Portage restricted resources which can be written by anyone in the Portage group. Some such resources could, if modified, cause problems. For example:

• /var/lib/portage/preserved_libs_registry - mode 660, root:portage. If truncated, Portage would not handle previously preserved shared libraries as expected.
• /var/log/emerge.log - a long running log of everything you have ever emerged. Losing it would not hurt Portage, but some people find its content to be useful, so if lost, it would need to be restored from a backup.

As you can imagine nobody will search entire forum trying to figure out if this solution was every provided and being deem inappropriate.

I believe it is documented in Gentoo handbook in *User administration* section suggest daily user to be place in *portage* group to *Be able to access portage restricted resources.*

Do you have a citation for this?

Yes, as it is documented in Gentoo handbook in User administration/Adding a user for daily use.

Changing permissions to mode 777 is almost always the wrong solution. Please do not recommend this without an explanation of why it is appropriate.

I understand from security point of view making a directory permission open wide is not a good practice. However my suggestion is direct point for using *sudo* which change effect UID to *root* and therefor the directory must allow *root* to create new file in order for the sudo method to work. And without going through how the exact environment was setup, it would be much quicker to use a command to illustrate the setup to allow root write access. I would think for security concern using *sudo* to perform this task is inappropriate in the first place, would you agree?

The user must run the command with uid root, either from a root shell or from a sudo call. I don't see how one is worse than the other here. Popular sudo configurations are less secure than I like, but that is outside the scope of the problem.

Agree, in this particular case running root shell or using sudo post no significant different.

However I hold a different opinion in compare open directory wide vs use root execution. In this case in particular I ask the user open a directory very deep in a directory tree, not at some arbitrated top level directory where other might accidentally travail into. So I cannot accept saying me suggest "Changing permission to mode 777 is almost always the wrong solution". Whereas use root execution might post even greater risk to entire system due to intention or mistake in script. Allow me share my previous work experience, One of my junior system admin try to clean up a temporary file location, he created cron job under root eventually wipe out entire system. According to his explanation, He first tried use his own id to create the cron job calling sudo to delete everything in the temporary file location failed due to sudo in cron asking for input. So he think root will be able to delete any way so he changed to place the script under root crontab, And under root crontab he succeed for one day, the next day the cron job kick in wipe out the entire system, and he was not able to understand what happen. After I restore the system and check his crontab script I found he perform a cd tmpdir then rm *, however some other system tidy script remove the tmpdir due to it is a empty directory, so the next day the crob job kick in, the cd tmpdir failed due to the tmpdir not exist and the rm * performed at / and that wipe out the entire system.

As pjp described, any permissions mechanism that can block root will likely block root whether the permissions are strict or are world-everything (0777). I suspect that in this case, the failing process wasn't really running as root, and so was falling victim to restrictive search permissions on a parent directory.

Finally curious mind like to learn, since I was not explain will, Would someone care enough to help me understand what is appropriate way to answer when someone want to use a risky method (using sudo) in the place were risky method already executed but still encounter error and the solution to address the error.

@Hu, if you review the post by the OP you will see OP posted a

Code: Select all

sudo ebuild sc-im-0.8.2.ebuild manifest

with error message which in particular stated that

Code: Select all

/usr/lib/portage/python3.9/ebuild.sh: line 645: /home/ari/Ari/coding/resources_/dinolay/app-office/sc-im/sc-im-0.8.2.ebuild: Permission denied

. I happen to run into this error before and that is why I suggest chmod 777 will fix this error.

The solution is to understand the error, and then perform a targeted fix for the error, rather than switch to an even more risky method. Opening the permissions does nothing to understand the error, and so does nothing to explain whether that is a good approach. However dangerous sudo may be, it at least has the small virtue that it elevates the named process, so when the process exits, the elevated risk ends (assuming the process did not make filesystem changes that perpetuate the risk, such as installing an unrestricted setuid binary). Changing filesystem permissions is permanent until revoked by the owner, and users could easily forget to revoke the change if the revocation is not done immediately.

I accept the criticism of not bring out the risk of open directory wide access and should place warning to suggest change permission back after execution.

But if one need to bring out a solution for this problem would have been ask why Gentoo require use root in order to develop. So once a procedure require elevated right whomever execute should already understood the risk of the procedure and where possible risks might rise and how to overcome the risk. Using chmod 777 dir just a pointer to help understand how the execution error result is about.

[pingtoo]

sudo seems to remove risk compared with using root directly, so I still don't understand that point.

Using permissions 777 adds risk compared with using a more restricted mode.


While looking for solutions to problems, I've seen recommendations to set 777 on files or directories accessible by web server software. That seems like a solution worse than the original problem. In my opinion, there are few if any situations that can justify such an approach. Maybe an extremely isolated test environment, but even then it seems questionable.

The human factor seems to tend toward the easy path which may make such approaches more risky than they first appear.

Please have a look my answer to Hu's point. In particular the experience I had in my work.

and Yes I agree use permission 777 add risk. I am not arguing that. I am saying I asked open wide in a directory located in very deep in tree and unlikely a place other travel into, why is that so bad that need to be point out. I apologize not bring out this sooner. And I accept that I am didnot bring out a warning, that should change back after test.

[pietinger]

One of my junior system admin try to clean up a temporary file location, he created cron job under root eventually wipe out entire system. According to his explanation, He first tried use his own id to create the cron job calling sudo to delete everything in the temporary file location failed due to sudo in cron asking for input. So he think root will be able to delete any way so he changed to place the script under root crontab, And under root crontab he succeed for one day, the next day the cron job kick in wipe out the entire system, and he was not able to understand what happen. After I restore the system and check his crontab script I found he perform a cd tmpdir then rm *, however some other system tidy script remove the tmpdir due to it is a empty directory, so the next day the crob job kick in, the cd tmpdir failed due to the tmpdir not exist and the rm * performed at / and that wipe out the entire system.

After this your junior system admin learned "cd /tmdir && rm *" ...

You can never be save against people do human mistakes, but changing directories to 777 is complete wrong. If someone needs access build some groups and give 770. If it is a file owned only by root, then there is a hard reason for it ... then only root should work there.

Installing software on a computer system is a task for a system admin / root user, because you can wipe out or change any - security - software.

[Hu]

I believe it is documented in Gentoo handbook in *User administration* section suggest daily user to be place in *portage* group to *Be able to access portage restricted resources.*

Do you have a citation for this?

Yes, as it is documented in Gentoo handbook in User administration/Adding a user for daily use.

That section documents various important groups. It does not suggest that the user should be a member of all, or even most, of them.

I understand from security point of view making a directory permission open wide is not a good practice. However my suggestion is direct point for using *sudo* which change effect UID to *root* and therefor the directory must allow *root* to create new file in order for the sudo method to work. And without going through how the exact environment was setup, it would be much quicker to use a command to illustrate the setup to allow root write access. I would think for security concern using *sudo* to perform this task is inappropriate in the first place, would you agree?

Your phrasing is confusing, but no, I don't think I agree here.

However I hold a different opinion in compare open directory wide vs use root execution. In this case in particular I ask the user open a directory very deep in a directory tree, not at some arbitrated top level directory where other might accidentally travail into.

The root user normally has CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH, which would allow it to completely ignore traditional Unix permissions.

Code: Select all

# mkdir -m0 abc
# touch abc/def
# ls -la abc
total 0
d--------- 2 root root  60 ./
drwx------ 7 root root 160 ../
-rw-r----- 1 root root   0 def

If a process gets Permission denied, then either:

• The process lacks CAP_DAC_OVERRIDE+CAP_DAC_READ_SEARCH.
• There is an active layered security module which can confine even users with those capabilities.

If the process lacks CAP_DAC_OVERRIDE+CAP_DAC_READ_SEARCH then either it isn't actually root, or it dropped those capabilities. Either way, that suggests it needs a permission grant along the entire tree. Setting an inner directory to mode 777 is useless if a parent directory lacks search permission for the caller. This comes back to my earlier point: changing the permissions on one directory, without understanding why the existing permissions do not work, is not the right solution. At best, it will happen to allow the user to work, and probably teach the user a bad habit. At worst, it will do nothing, and the user will have opened permissions for nothing - and possibly learned the bad habit anyway. Faced with a permissions problem, the right course of action is to understand why the existing grants are insufficient. This is especially true when the existing grant appears to be root.

So I cannot accept saying me suggest "Changing permission to mode 777 is almost always the wrong solution".

You are welcome to ignore the advice. That does not mean you will not get called on it again later.

Whereas use root execution might post even greater risk to entire system due to intention or mistake in script.

Yes, of course irresponsible or uninformed use of root is dangerous. Your junior administrator was clearly both irresponsible and uninformed. Irresponsible for putting a dangerously broad cleanup job into service without better testing. Uninformed for not knowing of, and using, some simple sanity checks that could have mitigated its damage.

Allow me share my previous work experience, One of my junior system admin try to clean up a temporary file location, he created cron job under root eventually wipe out entire system. According to his explanation, He first tried use his own id to create the cron job calling sudo to delete everything in the temporary file location failed due to sudo in cron asking for input.

He should have known better than to think calling sudo from a cronjob would work.

After I restore the system and check his crontab script I found he perform a cd tmpdir then rm *, however some other system tidy script remove the tmpdir due to it is a empty directory, so the next day the crob job kick in, the cd tmpdir failed due to the tmpdir not exist and the rm * performed at / and that wipe out the entire system.

I've lost count of how many times I've heard variations of this story. It's shockingly common for people to assume cd never fails. Although the damage was not quite as impressive, I have a very similar story from a few years back. A novice user chained together cd place ; rm *, and proceeded to delete most of his home directory when place didn't exist.

As pietinger says, a simple use of && could have saved your junior administrator. Personally, I would use the more comprehensive set -eu. Of course, if at all possible, I wouldn't use rm * even if I was sure I was in the right directory. There are other ways of performing a wild delete, some of which can do a much better job of failing safely. The first that comes to mind here would be find tmpdir -mindepth 1 -delete, with some tweaks if recursion is needed.

I suspect that in this case, the failing process wasn't really running as root, and so was falling victim to restrictive search permissions on a parent directory.

@Hu, if you review the post by the OP you will see OP posted a

Code: Select all

sudo ebuild sc-im-0.8.2.ebuild manifest

with error message which in particular stated that

Code: Select all

/usr/lib/portage/python3.9/ebuild.sh: line 645: /home/ari/Ari/coding/resources_/dinolay/app-office/sc-im/sc-im-0.8.2.ebuild: Permission denied

. I happen to run into this error before and that is why I suggest chmod 777 will fix this error.

As I said, I think the process wasn't running as root. Yes, the user ran sudo, but the called process could easily change itself to a non-root uid.

But if one need to bring out a solution for this problem would have been ask why Gentoo require use root in order to develop.

Does it? I would expect that with the right environment, to avoid trying to write to root-only resources, one could write an ebuild and digest it without root. Running it will likely require root, but Portage's sandbox features do a pretty good job of keeping people out of trouble - assuming the user is not actively trying to circumvent them.

[pingtoo]

One of my junior system admin try to clean up a temporary file location, he created cron job under root eventually wipe out entire system. According to his explanation, He first tried use his own id to create the cron job calling sudo to delete everything in the temporary file location failed due to sudo in cron asking for input. So he think root will be able to delete any way so he changed to place the script under root crontab, And under root crontab he succeed for one day, the next day the cron job kick in wipe out the entire system, and he was not able to understand what happen. After I restore the system and check his crontab script I found he perform a cd tmpdir then rm *, however some other system tidy script remove the tmpdir due to it is a empty directory, so the next day the crob job kick in, the cd tmpdir failed due to the tmpdir not exist and the rm * performed at / and that wipe out the entire system.

After this your junior system admin learned "cd /tmdir && rm *" ...

You can never be save against people do human mistakes, but changing directories to 777 is complete wrong. If someone needs access build some groups and give 770. If it is a file owned only by root, then there is a hard reason for it ... then only root should work there.

Installing software on a computer system is a task for a system admin / root user, because you can wipe out or change any - security - software.

@pietinger, Appreciate your input. I cannot say I agree wholly the statement

changing directories to 777 is complete wrong

because there are circumstance require share access but because no root access therefor you open it up just so sharing can happen. But in general I do agree we should not change directories 777 just because I got a permission denied error.

@pietinger, you may or may not aware in OP the user ran in to permission denied error after someone given advise use sudo to run ebuild command. It turn out the user create a project directory in the user's home directory and the ebuild file located in this project directory and the error messages seems to indicate no permission on the ebuild file itself. The reason I ask OP to chmod 777 dir is to point out that it is not the ebuild have permission problem, it is the project directory need to open up in order to create the manifest file. Please note when I give the advise use chmod 777 *dir* the *dir* I gave in the example are full path to the project dir, I did not advise to open up the user's home directory or anywhere else.

Installing software on a computer system is a task for a system admin / root user, because you can wipe out or change any - security - software.

This is where Gentoo design create a dilemma; I totally agree install software is a system admin task; However is a developer wish to port a application into Gentoo also need to be system admin?

[pietinger]

However is a developer wish to port a application into Gentoo also need to be system admin?

For his own computer: Yes. This should be no problem.
For your company's system: No ... because he is not allowed to install software. This is a system admin's task (4-eyes-principle).

[dmpogo]

[
This is where Gentoo design create a dilemma; I totally agree install software is a system admin task; However is a developer wish to port a application into Gentoo also need to be system admin?

Developer who ports his application to Gentoo should test his ebuilds/application in the environment that Gentoo users have. Which does not include directories with add-hoc changed permissions.

[pingtoo]

To help reading and reduce complexity of overall concept I only copy from relevant sections.

Do you have a citation for this?

Yes, as it is documented in Gentoo handbook in User administration/Adding a user for daily use.

That section documents various important groups. It does not suggest that the user should be a member of all, or even most, of them.

I believe in contrast, The document did suggest if one wish to perform task related to portage than one should place the user in portage group.

The groups the user is member of define what activities the user can perform.

portage Be able to access portage restricted resources.

I understand from security point of view making a directory permission open wide is not a good practice. However my suggestion is direct point for using *sudo* which change effect UID to *root* and therefor the directory must allow *root* to create new file in order for the sudo method to work. And without going through how the exact environment was setup, it would be much quicker to use a command to illustrate the setup to allow root write access. I would think for security concern using *sudo* to perform this task is inappropriate in the first place, would you agree?

Your phrasing is confusing, but no, I don't think I agree here.

I am sorry that I did not make my phrase clearly. English is not my first language. My point is use chmod 777 dir(I hope this way is more clearly) in a leaf of a very deep tree branch is not as bad practice as you indicated.

As you continue to argue chmod 777 is bad, and I continue to argue my point is this is case specific, So I think maybe we are not talking same concept.

However I hold a different opinion in compare open directory wide vs use root execution. In this case in particular I ask the user open a directory very deep in a directory tree, not at some arbitrated top level directory where other might accidentally travail into.

The root user normally has CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH, which would allow it to completely ignore traditional Unix permissions.

Code: Select all

# mkdir -m0 abc
# touch abc/def
# ls -la abc
total 0
d--------- 2 root root  60 ./
drwx------ 7 root root 160 ../
-rw-r----- 1 root root   0 def

If a process gets Permission denied, then either:

• The process lacks CAP_DAC_OVERRIDE+CAP_DAC_READ_SEARCH.
• There is an active layered security module which can confine even users with those capabilities.

Another possibility the path is part of NFS mount and the NFS share map root to someone else. example,

Code: Select all

root # mkdir /tmp/testdir
root # exportfs -o rw :/tmp/testdir
root # mkdir /tmp/testdir/user/devel/project/app-misc/abc
root # chown -R user:users /tmp/testdir/user
root # chmod 0700 /tmp/testdir/user
root # chmod 0700 /tmp/testdir/user/devel/project
# create another dir as NFS mountpoint
root # mkdir /tmp/testmnt
# mount NFS share created in previous steps
root # mount localhost:/tmp/testdir /tmp/testmnt
# Now switch to user
user $ chmod 777 /tmp/testmnt/user/devel/project/app-misc/abc
#
# at this point the NFS mount tree path have permission as follow,
#
# /tmp/testmnt/user <---------------------------- 0700 (drwx------ user users)
# /tmp/testmnt/user/devel <---------------------- 0755 (drwxr-xr-x user users)
# /tmp/testmnt/user/devel/project <-------------- 0700 (drwx------ user users)
# /tmp/testmnt/user/devel/project/app-misc <----- 0755 (drwxr-xr-x user users)
# /tmp/testmnt/user/devel/project/app-misc/abc <- 0777 (drwxrwxrwx user users)
#
user $ cd /tmp/testmnt/user/devel/project/app-misc/abc
# Using sudo to demonstrate if the OP was using NFS the chmod 777 will fix the sudo error.
user $ sudo touch Manifest && ls -l
total 0
-rw-r--r-- 1 nobody nobody 0 Sep 14 15:57 Manifest
# assume another user want to investigate what the "user" have, (using root to pretend the *other user*)
user $ cd /tmp
user & sudo ls -lR /tmp/testmnt/user
ls: cannot open directory '/tmp/testmnt/user': Permission denied
# Try as another user want to do something to the *user* for fun (again use root to pretend the *other user*)
user $ sudo touch /tmp/testmnt/user/devel/project/app-misc/abc/hay-fun-file
touch: cannot touch '/tmp/testmnt/user/devel/project/app-misc/abc/hay-fun-file': Permission denied

If a process gets Permission denied, then either:

• The process lacks CAP_DAC_OVERRIDE+CAP_DAC_READ_SEARCH.
• There is an active layered security module which can confine even users with those capabilities.

Thanks for the information. I don't know much about linux capabilities, You learn everyday!

The story I shared is not intent to discuss what is correct way to write a script to clean up. It is mean to illustrate that not understand what sudo/root-shell can do can post greater risk to system than chmod 777. So my point is my advise of perform chmod 777 in compare to use sudo to address the Permission Denied error message, the chmod 777 is less risky, especially it is deep in a tree path where tree top already have protection prevent wrongful access.

[pingtoo]

[
This is where Gentoo design create a dilemma; I totally agree install software is a system admin task; However is a developer wish to port a application into Gentoo also need to be system admin?

Developer who ports his application to Gentoo should test his ebuilds/application in the environment that Gentoo users have. Which does not include directories with add-hoc changed permissions.

In this case what is the environment?

in the environment that Gentoo users have

The OP of this original thread was at beginning of the test of Gentoo ebuild. OP want to create manifest.

[pingtoo]

However is a developer wish to port a application into Gentoo also need to be system admin?

For his own computer: Yes. This should be no problem.
For your company's system: No ... because he is not allowed to install software. This is a system admin's task (4-eyes-principle).

That is why I call it is a dilemma, I think OP is the owner of the computer. But from the OP thread, he/she does not have mush system-admin experience.