Tag Info

New answers tagged

0

It seems that your file is in DER binary format. You first need to convert the file into e.g PEM format. To verify the file is in DER binary format run: openssl rsa -in /root/Desktop/PROIVA -inform der -noout -text If it returns something like the following, then it is indeed in DER format. Private-Key: (1024 bit) modulus: ...


0

1) In general, files in /var/www should be owned by root:www-data and chmod 644. They should not be writable by the www-data user unless absolutely necessary (and that goes triple for executable files) because files which are writable by www-data can be modified by an attacker who manages to compromise the web server itself or a script run by the web server ...


0

(1) chmod and chown are different commands. The first sets permissions and the second ownership. You may wish to also run `find /var/www/html -exec chown www-data:www-data {} +` in addition to the commands you are already running, but that is a choice for you to make. (2) You can edit /etc/cron.allow and add www-data to allow the www-data user to run ...


8

If you don't want to be challenged every time for your password then I'd recommend setting it to NOPASSWD in your /etc/sudoers file rather than hardcode your password in your logins. At least this way your primary login's password will remain intact and not be completely exposed in your .bashrc. To make this change run the command sudo visudo, and change ...


0

Most filesystems designed for Unix/Linux can be mounted with a nosuid attribute, which will prevent setuid or setgid binaries located on those filesystems from altering the effective uid or gid of a process. It's often used when mounting "untrusted" filesystems, those that are under the control of a non-administrator. In your case, the filesystem you're ...


1

If you fiddled with your home directory, you needed root to get at the /home directory that contains it. Possibly your home now contains some stuff owned by something other than you, that the sudo obviates. An aggressive approach might be "sudo chown -R myname:users ~myname" A more cautious person might do "find ~myname ! -user myname" to look for such ...


2

SetUID bit on executable allows to run executable at file owner (not superuser). To be able to run executable as root, execute: sudo chown 0:0 ./setuid-test


1

When a program wants to read or write to a file, it needs to call the system call open() for the file first. One of the arguments to the call specifies which operations the program wants to be able to do. It the program indicates it wants to read or write the file, and the process does not have the perspective for the operations, the open() call ends up in ...


3

When user tries to access a file or directory, the kernel allows to opens the file or directory with the mode parameter set to what permissions is assigned for that particular user. So if the user has only read permission the file opened by an application will be given only to read the contents of the file by the kernel.


0

RWX permissions control how users on the system can interact with files. For example, the Root user can do anything to a file. whereas a standard user's access to a particular file is governed by the permissions of that file. As far as I know the OS doesn't directly interact with files itself. But instead uses system user accounts which in turn obey the file ...


0

This looks more like a permissions problem to me than a read-only filesystem. From the pi, can you make the /export/data directory temporarily world-writable? If so, can you now write from the client? When you create a file this way, who is the owner? Without no_root_squash, your root user is mapped to nobody. Otherwise, you'll need to map the user from ...


3

I guess its pretty clear from the Man pages. And by the way what is your question? What part of the man page is not clear to you? With the execute bit set you have the permission to cd into the directory Also for long listing ls -l i.e. to view the meta data of the files inside the directory (Provided that read permission is there for the directory.


7

Install auditd and run: sudo auditctl -a exit,always -F arch=b64 -S fchmod -S chmod -S fchmodat \ -F path=/dev/null -k dev-null-chmod sudo auditctl -a exit,always -F arch=b32 -S fchmod -S chmod -S fchmodat \ -F path=/dev/null -k dev-null-chmod You'd find the culprit in the output of: sudo ausearch -ik dev-null-chmod You'll see the command name, pid ...


1

Your file has the immutable extended attribute set, which is why you can't delete it. lsattr returns the extended attributes on the file: $ lsattr model/DailyUpdateClass.class -u-Diad--j------ DailyUpdateClass.class You will need to decipher all of the letters (-u-Diad--j) The man page for lsattr will tell you to look at the man page for chattr for a ...


1

A user can not delete readonly snapshots directly, but he can make them writeable first and then delete them. For this you need to use the btrfs property command: btrfs property set -ts /path/to/snapshot ro false If the user is the owner of the snapshot, this should make it writeable and therefore deletable.


1

the ownership is preserved, but probably you dont have the same users in both enviroments. check the user id of by example user www-data in both servers and compare it. you may see another name, but the id will be the same


1

rsync can't preserve ownership if it's being run by a non-root user on the destination system, because only the superuser is allowed to create files that are owned by someone else. Instead of using rsync create a tar file on the intermediate system. Then when you restore it on the ultimate target system, you can do so as root in order to give the original ...


2

You can have run.sh with "read by all" privilegs, but if e.g. /var/www/ is with privilegs "read only by root" you will get "permission denied" error message. check permissions of all directories in the path /var/ /var/www/ /var/www/etherpad-lite/ /var/www/etherpad-lite/bin/


4

You've recursively changed permission on every file under root (/) and also filename. This is because you've a space between the two. You a few options: Fix the permissions. This will involve trying to figure out the correct permission for every file under / - a very time consuming task. One possible way to do this would be to install another copy of ...


1

You gave an unneeded space after the slash. Your terminal problems will be fixed by a reboot. These permissions are long in a ramfs-based filesystem which will be reconstructed on every reboot. But warn: you system is currently probably unbootable, thus after a reboot you started probably on a rescue system. If you don't have a backup, you need to know, ...


4

Gilles is correct; this is due to the changes in xorg-server 1.16 which were announced on the Arch News. To work around the permissions issue, you can use a Xorg.wrap config file to pass root rights, using: needs_root_rights = yes See man Xorg.wrap for the details. You could also try using xf86-video-modesetting instead of xf86-video-fbdev until the ...


1

The directory /tmp must have the permissions 1777 = rwxrwxrwt, i.e. everybody can read, write and access files in the directory, and (t = sticky bit) files may only be deleted by their owner. A lot of things will stop working if this isn't the case, sometimes in bizarre ways. sudo mkdir -m 1777 /tmp or sudo mkdir /tmp && sudo chmod 1777 /tmp ...


1

If you access the disk using a filemanager then the partition is mounted in: /run/media/<username>/<label or uuid> Only the user which used the filemanager has permissions to this partition. To make the partition visible to others, you'll need to add it to /etc/fstab. For example: /dev/sdb1 /media/mystuff ext4 defaults 1 2 ...


5

/tmp can be considered as a typical directory in most cases. You can recreate it, give it to root (chown root:root /tmp) and set 1777 permissions on it so that everyone can use it (chmod 1777 /tmp). This operation will be even more important if your /tmp is on a separate partition (which makes it a mount point). By the way, since many programs rely on ...


5

mv does not make a copy of the file and remove the original, unless you're moving the file between different filesystems. mv moves the file. In order to move a file, you need to have permission to detach it from the directory where it was before, and to attach it to the directory where you're putting it. In other words, you need write (and execute) ...


4

A number of possibilities: the trailing dot in the file permissions line -rwSr-s---. indicate extended permissions, either SE Linux (confirm with ls -lZ) or ACL style permissions (confirm with getfacl ) which may block root overrides. the file has been made immutable with chattr ; confirm the file system attributes with lsattr The file is on a NFS ...


3

This is required by the POSIX standard for mkdir: For the -p option: Create any missing intermediate pathname components. followed by: and then calling the chmod() function with the following arguments: The same path argument as in the mkdir() call The value (S_IWUSR|S_IXUSR|~filemask)&0777 as the mode argument, where filemask is ...


0

mount -o rw,remount /foo will remount /foo mount point rw. If there is a /foo/bar mount point (whether ro or rw), the mount command will likely fail. If there are /foo/what and /foo/ever directories, those will be rw as well. If your read-only mount point is /foo /bar /baz then mount -o rw,remount /foo will keep other mount points read only.


0

I found a way of editing the /etc/fstab config file so that you can create a bind mount: /my/real/dir /to/mount/dir <filesystem> rw,bind 0 0 none - No options associated with mount point (like quotas) rw - The mount point is read and writeable. bind - The mount point is a bound directory filesystem - ext2,ext3,vfat,etc.


1

Your understanding is pretty much correct. A better way to think of the execute permission is that it allows you to do things with a file or directory name in the directory (other than just reading the name itself). Most of those things involve translating the name to an inode, but it also includes creating new names and removing existing names. Write ...


0

If you want to do something like this you'll have to use a restricted sudo rule (like this): user ALL=(root) /bin/ls -l /proc/* using the sudoers command (as root of course :-)1023) The "user" would then type in: sudo /bin/ls -l /proc/.... to get the information.


2

You actually can't set permissions for many entries in procfs (in Linux at least) at all - they are handled by the kernel itself.


-1

In Puppy Linux, by default you can execute scripts on NTFS or FAT partitions: http://murga-linux.com/puppy/viewtopic.php?t=95174


3

This happens because you're only running the echo command as root. The output redirect is handled by your (non-root) shell. To avoid this, don't use the shell's redirect and use an actual command to handle the writing: tee. What you want to do can be done as so: echo "xyz" | sudo tee test > /dev/null (if you don't redirect the output, tee will output xyz ...


-2

sudo has to cover whole redirection in order it can be completely executed under root: $ sudo sh -c “usr/bin/echo 3 > /proc/sys/vm/drop_caches”


2

rsync only preserves the owner if you ask it to with -o — otherwise files will be owned by the user running the rsync command, just like when any other files are created. -a includes -o, however, so lots of common rsync command lines include it. man rsync includes a passage on this explicitly: For example: if you want to use -a (--archive) but don’t want -o ...


0

As far as the kernel is concerned, a process runs as a user¹ and one or more group. Once the process is started, it won't acquire more groups. A process inherits its user and group(s) from the process that calls it. The notion of a user belonging to a group is managed by user administration tools, and it's the login program that bestows group memberships ...


0

$ ls -l /usr/bin/crontab -rwsr-xr-x 1 root root 36K Jul 3 2012 /usr/bin/crontab The ownership and permission should actually be -rwxr-sr-x 1 root crontab 35880 Jul 3 2012 /usr/bin/crontab Since Debian sarge, crontab is setgid crontab, not setuid root, as requested in bug #18333. This is the cause of your problem: the crontab program expects to ...


0

Your old disks are probably formatted with ext3 or ext4. Both of those filesystems have permissions (unlike, for example, FAT which doesn't). And unfortunately, its not possible to disable permissions on them. So when you're mounting the old drives (no matter how you do it—on the command line or via double-clicking in the GUI), the system is going to look ...


2

What about: sudo rm directory/filename or: su -c "rm directory/filename" depending on your distro and/or setup. You are giving yourself a temporary root for the duration of the above commands and as root is almighty on Unix/Linux you are allowed to do anything. This contrasts with MS Windows where you can remove access to the administrator account ...


1

It seems that Udev (which is in the man) manages dynamic devices like USB devices when they're plugged in. It'll then instantiate them in /dev somewhere. (Like /dev/bus/usb/002 in my case.) This /dev node has to have some permissions, Udev takes the permissions from the files in /lib/udev/rules.d/, there's some arcane syntax which matches a device to an ...


1

It doesn't make sense if the unix file permissions disagree to the acl entry and vice versa. Accordingly, the manual page (acl(5)) says what you ask for: CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS The permissions defined by ACLs are a superset of the permissions specified by the file permission bits. There is a correspondence ...


2

You can do this using udev. Create a file in /etc/udev/rules.d with the suffix .rules, e.g. local.rules, and add a line like this to it: ACTION=="add", KERNEL=="i2c-[0-1]*", MODE="0666" MODE=0666 is rw for owner, group, world. Something you can do instead of, or together with that, is to specify a GID for the node, e.g: GROUP="pi" If you use this ...


1

The reason for EPERM (the permission denied error ) is here: drwxr-xr-x 5 www-data www-data 4096 juil. 30 13:47 . The directory where you are trying to create a file (in other words change contents of the directory-file) is writeable only for user www-data, which you are not. Either mark the directory as writeable for the group, change the user to ...


2

tl;dr Access is determined by the user who is running application, and sudo runs applications as different user. Full version: How does the OS know that a command needs sudo? It doesn't know. UNIX manages permissions not on application level but on filesystem level: permissions are granted for users to access specific files. Applications then are run ...


1

This may be splitting hairs, but: to execute a file, you must have execute permission to the file and all the directories you navigate to get to the file.  So, if Tom has a program (do_interesting_stuff) in his home directory (/home/tom), and the directory is protected 700 (no access for anyone but owner) but the file is protected 755 (read and execute ...


3

See the Wooledge wiki on tests and conditionals: -w FILE: True if the file is writable by you. So, you could test it with: [[ -w "$file" ]] If you aren't using bash, you could equally use [ -w "$file" ]


4

su and sudo are privileged programs. su changes (after successful authentication) the real and effective user and group id to that of the user you su to. Thus, su is similar to login. Note that su can be used to change to any user, not just root. sudo also changes the real and effective user and group ids. Up to this point su and sudo are similar (but ...


12

Sometimes the "Permission denied" message is due to filesystem permissions denying you write access, for example. The executable/tool simply checks if it the filesystem grants you enough permissions to do what you're about to do and throws an error if it's denied by the filesystem. Other times, the tool itself will check your user ID before allowing you to ...


22

For the purposes you have described, the OS doesn't decide whether you need sudo to initially run the program. Instead, after the program starts running and then tries to do something that is not permitted by the current user (such as writing a file to /usr/bin to install a new command), the OS prevents the file access. The action to take on this condition ...



Top 50 recent answers are included