I have two Users. User1 is running a program which tries to delete a file from user2. But my program always return me "permission denied".
When I try to delete the file myself as user1 with the rm command there is no problem. The permission of the files are 775 and my user1 is in the group of user2. This group is also the owner of the files. The permission of the directory in which the files are is 775 too.
For removing the file the program I have written uses the "remove" function from c/c++.
Does anyone have a solution or idea ?
I have asked this question on unix.stackexchange.com before. They have sent me here.
Here is my code:
void deleteFile()
{
if(0 != remove("File1.txt"))
cout<<"Error deleting File: "<<strerror(errno)<<endl;
if(0 != remove("File2.txt"))
cout<<"Error deleting File: "<<strerror(errno)<<endl;
}
i have renamed the files but i know the original paths are correct. i have already tested this
more information:
ok i have runnned the program as user2 and the files have been deleted without any problems.
groups user1
users user2
groups user2
user2 adm www-data plugdev users ftp vsftpd
ls -lah
drwxrwxr-x 7 user2 user2 4.0K Nov 27 14:13 .
drwxrw-r-x 4 user2 user2 4.0K Nov 11 12:34 ..
-rwxrwxr-x 1 user2 user2 50 Nov 12 15:12 File1.txt
-rwxrwxr-x 1 user2 user2 826 Nov 27 14:13 File2.txt
Try running rm and Your command with strace as user1:
strace your_program
strace rm File1.txt File2.txt
You should see, what Your program and rm are doing differently.
Related
When trying to SSH to GCE VMs using metadata-based SSH keys I get the following error:
ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
While troubleshooting I can see the keys in the instance metadata, but they are not being added to the user's authorized_keys file:
$ curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/attributes/ssh-keys"
username:ssh-ed25519 AAAAC3NzaC....omitted....
admin:ssh-ed25519 AAAAC3NzaC....omitted....
$ sudo ls -hal /home/**/.ssh/
/home/ubuntu/.ssh/:
total 8.0K
drwx------ 2 ubuntu ubuntu 4.0K Aug 11 23:19 .
drwxr-xr-x 3 ubuntu ubuntu 4.0K Aug 11 23:19 ..
-rw------- 1 ubuntu ubuntu 0 Aug 11 23:19 authorized_keys
# Only result is the default zero-length file for ubuntu user
I also see the following errors in the ssh server auth log and Google Guest Environment services:
$ sudo less /var/log/auth.log
Aug 11 23:28:59 test-vm sshd[2197]: Invalid user admin from 1.2.3.4 port 34570
Aug 11 23:28:59 test-vm sshd[2197]: Connection closed by invalid user admin 1.2.3.4 port 34570 [preauth]
$ sudo journalctl -u google-guest-agent.service
Aug 11 22:24:42 test-vm oslogin_cache_refresh[907]: Refreshing passwd entry cache
Aug 11 22:24:42 test-vm oslogin_cache_refresh[907]: Refreshing group entry cache
Aug 11 22:24:42 test-vm oslogin_cache_refresh[907]: Failure getting groups, quitting
Aug 11 22:24:42 test-vm oslogin_cache_refresh[907]: Failed to get groups, not updating group cache file, removing /etc/oslogin_group.cache.bak.
# or
Aug 11 23:19:37 test-vm GCEGuestAgent[766]: 2022-08-11T23:19:37.6541Z GCEGuestAgent Info: Creating user admin.
Aug 11 23:19:37 test-vm useradd[885]: failed adding user 'admin', data deleted
Aug 11 23:19:37 test-vm GCEGuestAgent[766]: 2022-08-11T23:19:37.6869Z GCEGuestAgent Error non_windows_accounts.go:144:
Error creating user: useradd: group admin exists - if you want to add this user to that group, use -g.
Currently the latest cloud-init and guest-oslogin packages for Ubuntu 20.04.4 LTS (focal) seem to have an issue that causes google-guest-agent.service to exit before completing its task. The issue was fixed and committed but not yet released for focal (and likely other Ubuntu versions).
For now you can try disabling OS Login by setting instance or project metadata enable-oslogin=FALSE. After which you should see the expected results and be able to SSH using those keys:
$ sudo journalctl -u google-guest-agent.service
Aug 11 23:10:33 test-vm GCEGuestAgent[761]: 2022-08-11T23:10:33.0517Z GCEGuestAgent Info: Created google sudoers file
Aug 11 23:10:33 test-vm GCEGuestAgent[761]: 2022-08-11T23:10:33.0522Z GCEGuestAgent Info: Creating user username.
Aug 11 23:10:33 test-vm useradd[881]: new group: name=username, GID=1002
Aug 11 23:10:33 test-vm useradd[881]: new user: name=username, UID=1001, GID=1002, home=/home/username, shell=/bin/bash, from=none
Aug 11 23:10:33 test-vm gpasswd[895]: user username added by root to group ubuntu
Aug 11 23:10:33 test-vm gpasswd[904]: user username added by root to group adm
Aug 11 23:10:33 test-vm gpasswd[983]: user username added by root to group google-sudoers
Aug 11 23:10:33 test-vm GCEGuestAgent[761]: 2022-08-11T23:10:33.7615Z GCEGuestAgent Info: Updating keys for user username.
$ sudo ls -hal /home/username/.ssh/
/home/username/.ssh/:
total 12K
drwx------ 2 username username 4.0K Aug 11 23:19 .
drwxr-xr-x 4 username username 4.0K Aug 11 23:35 ..
-rw------- 1 username username 589 Aug 11 23:19 authorized_keys
The admin user however will not work, since it conflicts with an existing linux group. You should pick a username that does not conflict with any of the name:x:123: names listed at getent group
In a Dockerfile, the common way to copy a directory as a non-root user (e.g $UID 1000) is the following:
COPY --chown=1000:1000 /path/to/host/dir/ /path/to/container/dir
However, I want to use variables instead. For example
ARG USER_ID=1000
ARG GROUP_ID=1000
COPY --chown=${USER_ID}:${GROUP_ID} /path/to/host/dir/ /path/to/container/dir
But this is not possible. There exist a workaround?
Note I know that a possible workaround could be to copy the directory as root and then run chown on the directory (variables works fine with RUN). However, the size of the image will grow just for the use of chown in a separate command.
You can create a user before running the --chown;
mkdir -p test && cd test
mkdir -p path/to/host/dir/
touch path/to/host/dir/myfile
Create your Dockerfile:
FROM busybox
ARG USER_ID=1000
ARG GROUP_ID=1000
RUN addgroup -g ${GROUP_ID} mygroup \
&& adduser -D myuser -u ${USER_ID} -g myuser -G mygroup -s /bin/sh -h /
COPY --chown=myuser:mygroup /path/to/host/dir/ /path/to/container/dir
Build the image
docker build -t example .
Or build it with a custom UID/GID:
docker build -t example --build-arg USER_ID=1234 --build-arg GROUP_ID=2345 .
And verify that the file was chown'ed
docker run --rm example ls -la /path/to/container/dir
total 8
drwxr-xr-x 2 myuser mygroup 4096 Dec 22 16:08 .
drwxr-xr-x 3 root root 4096 Dec 22 16:08 ..
-rw-r--r-- 1 myuser mygroup 0 Dec 22 15:51 myfile
Verify that it has the correct uid/gid:
docker run --rm example ls -lan /path/to/container/dir
total 8
drwxr-xr-x 2 1234 2345 4096 Dec 22 16:08 .
drwxr-xr-x 3 0 0 4096 Dec 22 16:08 ..
-rw-r--r-- 1 1234 2345 0 Dec 22 15:51 myfile
Note: there is an open feature-request for adding this functionality:
issue #35018 "Allow COPY command's --chown to be dynamically populated via ENV or ARG"
In my case, I used my UID and GID numbers and it works as I do have the same non-root account in the DEV and PROD environments.
COPY --chown=1000:1000 /path/to/host/dir/ /path/to/container/dir
And you can find the user and group IDs with the linux command: id
I have setup a Django application, in which user can upload his image and it is served by Nginx and Gunicorn.
I have a problem with uploading large image files which does not get appropriate permissions to be served by Nginx
location /medias/images/ {
root /var/www/html;
}
When uploading files, the larger ones only get read permissions for the user, not for group/other:
-rw------- 1 user1 user1 4.9M Mar 15 14:35 File1.jpg
-rw------- 1 user1 user1 3.7M Mar 15 14:31 File2.jpg
-rw-r--r-- 1 user1 user1 110K Mar 15 14:44 File3.pdf
-rw-r--r-- 1 user1 user1 34K Mar 15 09:17 File4.docx
-rw-r--r-- 1 user1 user1 136K Mar 15 14:45 File5.jpg
-rw-r--r-- 1 user1 user1 92K Mar 15 14:22 File6.doc
-rw------- 1 user1 user1 4.4M Mar 15 14:25 File7.jpg
However the smaller images get their permissions fine and are served properly.
The point is that both uploading small and semi-large (3mb) image files are done by a same process.
Any ideas?
Set the FILE_UPLOAD_MAX_MEMORY_SIZE parameter in your Django settings, in Bytes.
For example FILE_UPLOAD_MAX_MEMORY_SIZE = 20971520 equals 20MB.
I want to create a shell script, that iterates through folders and deletes folders that match [versionnumber-n] where n > 0
the version number is in a file that's content is like:
MAVEN_VERSION=1.2.7.0-SNAPSHOT
Here's an example:
The file listing is like
drwxrwxr-x 4 jenkins jenkins 4096 Jul 29 10:54 ./
drwxrwxr-x 20 jenkins jenkins 4096 Jul 4 09:20 ../
drwxr-xr-x 2 jenkins jenkins 4096 Jul 23 12:35 1.2.6.0-SNAPSHOT/
drwxr-xr-x 2 jenkins jenkins 4096 Jul 28 23:13 1.2.7.0-SNAPSHOT/
-rw-rw-r-- 1 jenkins jenkins 403 Jul 29 10:11 maven-metadata-local.xml
-rw-r--r-- 1 jenkins jenkins 403 Jul 28 23:13 maven-metadata-mtx-snapshots.xml
-rw-r--r-- 1 jenkins jenkins 40 Jul 28 23:13 maven-metadata-mtx-snapshots.xml.sha1
-rw-r--r-- 1 jenkins jenkins 403 Jul 28 23:13 maven-metadata.xml
-rw-r--r-- 1 jenkins jenkins 32 Jul 28 23:13 maven-metadata.xml.md5
-rw-r--r-- 1 jenkins jenkins 40 Jul 28 23:13 maven-metadata.xml.sha1
-rw-r--r-- 1 jenkins jenkins 186 Jul 28 23:13 resolver-status.properties
Where I want the script to delete the folder 1.2.6.0-SNAPSHOT/ but not 1.2.7.0-SNAPSHOT/. If there where folders like 1.2.5.0-SNAPSHOT/ 1.2.4.0-SNAPSHOT/ them too.
What I have at this point:
.*(?!1.2.7.0)(-SNAPSHOT)
Which unfortunately matches both folders (in the example above)
edit: just hit submit too early ...
With Bash you can just use negation with extended pathname expansion.
shopt -s extglob
rm -fr /dir/1.2.!(7).0-SNAPSHOT
Dry run example:
$ ls -1
1.2.10.0-SNAPSHOT
1.2.5.0-SNAPSHOT
1.2.6.0-SNAPSHOT
1.2.7.0-SNAPSHOT
a
$ echo rm -fr 1.2.!(7).0-SNAPSHOT
rm -fr 1.2.10.0-SNAPSHOT 1.2.5.0-SNAPSHOT 1.2.6.0-SNAPSHOT
See Extended Pattern Matching and Filename Expansion.
How I did it in the end:
if [ -z "$MAVEN_VERSION_SERVER" ]
then
echo "\$MAVEN_VERSION_SERVER NOT set! \n exiting ..."
else
find /var/lib/jenkins/.m2/repository/de/db/mtxbes -mindepth 1 -type d -regex '.*SNAPSHOT' -not -name $MAVEN_VERSION_SERVER | xargs -d '\n' rm -fr
fi
(the $MAVEN_VERSION_SERVER gets set and read with groovy scripts before)
I'm on a shared linux server and I only have access to http://domain.com/~username/ which maps to ~/public_html.
I would like to use the Taffy framework for ColdFusion in this context. As far as I can tell, to use the framework you must have an Application.cfc that extends the Taffy framework component taffy.core.api.
https://github.com/atuttle/Taffy
https://github.com/atuttle/Taffy/wiki/Installing-Taffy
https://github.com/atuttle/Taffy/wiki/So-you-want-to:-Create-a-dead-simple-CRUD-API
The only directories I have access to are not sub-directories of the web root and therefore (as I understand it) not subsets of the ColdFusion path.
In my particular case I neither have access to CFADMIN nor are the server admins going to install a component I need to extend in a system-wide context where it is already on the path and accessible via global dot notation.
The instructions say you should unzip the taffy folder into your web root, and if you can't do that, you should make it a subfolder of your api. The former is not a possibility for me and when I do the latter I get "Could not find the ColdFusion Component or Interface taffy.core.api."
More Detail:
My api is at http://domain.com/~username/api/, so I unzipped /taffy to ~/public_html/api/. If I copy the Taffy example at taffy/examples/api to ~/public_html/api so that going to http://domain.com/~username/api/ should access the example, I get "Could not find the ColdFusion Component or Interface taffy.core.api" even if have taffy/core/api.cfc beneath that directory (~/public_html/api).
On this server I have successfully made cfc's that extend a cfc in another directory using <cfset THIS.mappings["/subdir"]= getDirectoryFromPath(getCurrentTemplatePath()) & "subdir/"> and <cfobject name="parentObj" component="subdir.parent">.
I have also successfully made an Application.cfc that extends a cfc in the same directory.
I just haven't successfully made an Application.cfc that can extend a cfc in another directory, even if it's a subdirectory.
I did try to use grep & related tools to strip every reference of "taffy.core" out of Taffy's source code so I could just dump all the taffy cfc's into my root directory along with Application.cfc so I could extend api.cfc, but I got different errors and didn't pursue that hacky solution any further.
<cfdump var=#expandPath('/mapping')# /> outputs /var/www/html/mapping.
uname#domain $>ls -la /var/www/html
drwxr-xr-x 3 root root 4096 Sep 16 00:34 .
drwxr-xr-x 7 root root 4096 May 28 2012 ..
lrwxrwxrwx 1 root root 19 Sep 16 00:34 cfide -> /var/www/html/CFIDE
drwxrwxr-x 10 apache root 4096 Sep 16 00:32 CFIDE
~/public_html/api/resources/successesCollection.cfc:
<cfcomponent extends="taffy.core.resource" taffy_uri="/successes">
<cffunction name="get" access="public" output="false">
<cfreturn representationOf('success').withStatus(200) />
</cffunction>
</cfcomponent>
~/public_html/api/Application.cfc:
<cfcomponent extends="taffy.core.api">
<!--- doesn't work
<cfset THIS.mappings["/taffy"]= getDirectoryFromPath(getCurrentTemplatePath()) & "taffy/">
<cfset THIS.mappings["/core"]= getDirectoryFromPath(getCurrentTemplatePath()) & "taffy/core/">
--->
<cfscript>
this.name = hash(getCurrentTemplatePath());
// do your onApplicationStart stuff here
function applicationStartEvent(){}
// do your onRequestStart stuff here
function requestStartEvent(){}
// this function is called after the request has been parsed and all request details are known
function onTaffyRequest(verb, cfc, requestArguments, mimeExt){
// this would be a good place for you to check API key validity and other non-resource-specific validation
return true;
}
// called when taffy is initializing or when a reload is requested
function configureTaffy(){
setDebugKey("debug");
setReloadKey("reload");
setReloadPassword("true");
// Usage of this function is entirely optional. You may omit it if you want to use the default representation class.
// Change this to a custom class to change the default for the entire API instead of overriding for every individual response.
setDefaultRepresentationClass("taffy.core.genericRepresentation");
}
</cfscript>
</cfcomponent>
Output of http://domain.com/~uname/api/index.cfm/successes/: Could not find the ColdFusion Component or Interface taffy.core.api.
Adding this to my Application.cfc doesn't fix the issue:
<cfcomponent extends="taffy.core.api">
<cfscript>
this.name = hash(getCurrentTemplatePath());
this.mappings = StructNew();
this.mappings['/taffy'] =
expandPath('./taffy');
In addition, adding the following to ~/public_html/api/Application.cfc doesn't fix the issue either:
<cfset this.mappings["/taffy"] =
expandPath(getDirectoryFromPath(getCurrentTemplatePath()) & "taffy")>
Check out the following sequence of commands and let me know if I've overlooked something. I'm still left with "Could not find the ColdFusion Component or Interface taffy.core.api" upon browsing to "http://domain/~uname/api".
[uname#domain ~]$ cd ~/public_html
[uname#domain ~/public_html]$ rm -rf api
[uname#domain ~/public_html/api]$ wget -O taffy.zip https://github.com/atuttle/Taffy/zipball/master
[uname#domain ~/public_html/api]$ unzip taffy.zip
[uname#domain ~/public_html/api]$ mv atuttle-Taffy-35df54e/ taffy
[uname#domain ~/public_html/api]$ mv taffy/examples/api .
[uname#domain ~/public_html/api]$ mv taffy api/
[uname#domain ~/public_html/api]$ tree -d ~/public_html/api/
~/public_html/api/
|-- resources
`-- taffy
|-- bonus
|-- core
|-- examples
| |-- ParentApplication
| | |-- config
| | |-- mixin
... etc
[uname#domain ~/public_html/api]$ ls -la ~/public_html/api/
total 8
drwxr-xr-x 4 uname ugroup 1024 Dec 9 11:00 .
drwxr-xr-x 10 uname web 1024 Dec 9 10:57 ..
-rw-r--r-- 1 uname ugroup 1188 Dec 9 11:00 Application.cfc
-rw-r--r-- 1 uname ugroup 172 Sep 20 13:04 .htaccess
-rw-r--r-- 1 uname ugroup 218 Sep 20 13:04 index.cfm
drwxr-xr-x 2 uname ugroup 1024 Sep 20 13:04 resources
drwxr-xr-x 8 uname ugroup 1024 Sep 20 13:04 taffy
[uname#domain ~/public_html/api]$ ls -la ~/public_html/api/taffy/
total 15
drwxr-xr-x 8 uname ugroup 1024 Sep 20 13:04 .
drwxr-xr-x 4 uname ugroup 1024 Dec 9 11:00 ..
drwxr-xr-x 2 uname ugroup 96 Sep 20 13:04 bonus
-rw-r--r-- 1 uname ugroup 4096 Sep 20 13:04 build.xml
drwxr-xr-x 2 uname ugroup 1024 Sep 20 13:04 core
drwxr-xr-x 15 uname ugroup 1024 Dec 9 10:57 examples
-rw-r--r-- 1 uname ugroup 99 Sep 20 13:04 .gitignore
drwxr-xr-x 2 uname ugroup 96 Sep 20 13:04 lib
-rw-r--r-- 1 uname ugroup 1356 Sep 20 13:04 LICENSE.TXT
-rw-r--r-- 1 uname ugroup 2490 Sep 20 13:04 ReadMe.md
drwxr-xr-x 3 uname ugroup 96 Sep 20 13:04 snippets
drwxr-xr-x 5 uname ugroup 1024 Sep 20 13:04 tests
[uname#domain ~/public_html/api]$ ls -la ~/public_html/api/taffy/core/
total 72
drwxr-xr-x 2 uname ugroup 1024 Sep 20 13:04 .
drwxr-xr-x 8 uname ugroup 1024 Sep 20 13:04 ..
-rw-r--r-- 1 uname ugroup 42382 Sep 20 13:04 api.cfc
-rw-r--r-- 1 uname ugroup 4574 Sep 20 13:04 baseRepresentation.cfc
-rw-r--r-- 1 uname ugroup 2572 Sep 20 13:04 dashboard.cfm
-rw-r--r-- 1 uname ugroup 1756 Sep 20 13:04 dashboard.css
-rw-r--r-- 1 uname ugroup 4538 Sep 20 13:04 docs.cfm
-rw-r--r-- 1 uname ugroup 3030 Sep 20 13:04 factory.cfc
-rw-r--r-- 1 uname ugroup 179 Sep 20 13:04 genericRepresentation.cfc
-rw-r--r-- 1 uname ugroup 3516 Sep 20 13:04 mocker.cfm
-rw-r--r-- 1 uname ugroup 389 Sep 20 13:04 nativeJsonRepresentation.cfc
-rw-r--r-- 1 uname ugroup 3765 Sep 20 13:04 resource.cfc
You do have a couple of options.
Mapping (per-application or otherwise)
As Taffy is a development framework, your sysadmin/host may be willing to install it in a central location for all developers to make use of. They could put the Taffy folder in the web root, or create a server-level mapping to wherever the folder may be.
Relative Path
It should be possible to run Taffy from a relative path. It sounds like this is the approach you're trying to take, but you may not have the files in the right locations.
In order to use relative paths, you need a directory structure that resembles:
~uname/api/
~uname/api/taffy/core/api.cfc <- Framework contents
~uname/api/taffy/core/factory.cfc
~uname/api/taffy/core/dashboard.cfm
~uname/api/taffy/core/...
~uname/api/taffy/...
~uname/api/Application.cfc <- your api code
~uname/api/index.cfm
~uname/api/resources <- where you put your resource CFC's
It sounds like you're missing the "taffy" folder and either put the CFC's directly in your api folder or put the "core" folder in your api folder.
The "taffy" folder is required. Think of the dot-notation path you're putting in your Application.cfc's extends attribute as a filesystem path. Since it's taffy.core.api then your filesystem needs to contain taffy/core/api.cfc.
Have you tried using a relative path proxy, as Ben Nadel explains here: http://www.bennadel.com/blog/2115-Extending-The-Application-cfc-ColdFusion-Framework-Component-With-A-Relative-Path-Proxy.htm
The idea is that your application.cfc would extend a local proxy (rootProxy.cfc) that resides in the same directory. That proxy then cfincludes the cfc you are interested in. Since cfinclude takes a relative path, you needn't worry about global dot notation or mappings.