Tag Info

New answers tagged

0

Most programs in /usr/bin should have permissions 755 — readable and executable by all, writable only by their owner, which is root. A few programs are setuid or setgid: they have extra privileges, which are confered by the setuid or setgid bit in the permissions. /usr/bin/sudo is one of them; it needs to be setuid root: chmod 4755 /usr/bin/sudo restores it. ...


3

Fortunately those permissions aren't complete destructive, but there is no "undo". If you can't restore from back-up and you haven't installed anything from source under /usr/bin you can potentially use the package manager to recover the correct permissions: For RPM based distributions (Red Hat Enterprise Linux, Fedora, CentOS etc.) doing so is fairly ...


1

Your external hard disk is likely using fat32 or a similar file system that doesn't support setting these permissions. In any case, making a mp3 file executable is at least dubious.


1

I have bad news for you: if I'm reading the code in http://lxr.free-electrons.com/source/fs/efs/ correctly, Linux -- even the very newest version -- does not implement write access to EFS, probably because it was believed that the only use for a filesystem that old was to migrate data off of old disks.


0

The permission udiskctl using is based on a polkit policy, look here for an example: https://wiki.archlinux.org/index.php/Udisks#Configuration Check what you current polkit policy states (in the arch example it grants the permission to the storage group). Either remove the user from the appropriate groups or modify the policy.


1

Is Filesystem the mount point? You could try the mount -o remount,rw -t efs /dev/sdb1 Filesystem option to remount the filesystem as read-write.


2

You can add the line bellow in the /etc/sudoers file: main_user ALL=NOPASSWD: /usr/bin/loginctl kill-user *


3

Also note that the error you gave above ln: creating symbolic link `/etc/init.d/jboss1': Permission denied is not due to the owner of the symlink being somebody else than the owner of the original file. It is (most probably) caused by user askar not having write access to the directory /etc/init.d.


5

Use attributes: chattr -R +i files (as root) will add the +i attribute recursively to your folders and files which will prevent ANY alternations. Note that root will also be locked and you would need to unset the i manually every time. Ownership and alike will be left unchanged.


-1

First change user and group to root chown -R root:root /tmp/uploads then change permissions so that only root can write chmod -R 755 /tmp/uploads EDIT: If you only need to restore files owners, I would save your files and owner in a file (There sure are better ways to do this, but this is the first thing that comes to my mind). Be sure ...


2

Not sure what you mean by "a directory and its users inside". The root user can always write to any file, so to make a file or directory writable only to root you make it non-writable by user, group, and others. Note that the webroot dir is supposed to be writable by the apache user, so what you're trying to do is to give it the incorrect permissions. ...


7

On a Linux system, when changing the ownership of a symbolic link using chown, by default it changes the target of the symbolic link (ie, whatever the symbolic link is pointing to). If you'd like to change ownership of the link itself, you need to use the -h option to chown: -h, --no-dereference affect each symbolic link instead of any referenced ...


2

When acting on symlinks, you must tell most of the tools (chown, chmod, ls...) not to dereference the link: you must add the -h parameter, as stated in the manpage : -h, --no-dereference affect symbolic links instead of any referenced file (useful only on systems that can change the ownership of a symlink) So try : sudo chown -h askar.admin ...


2

When you can not access to the directory you have right permissions, the first thing you should check is your access rights with parent directories: ls -ld /home/disk and: ls -ld /home/disk/disk1 You need at least execute permission to access the child of those directories.


1

There are two sets of FACL rules associated with folder ./appuser2: the FACL rules for folder ./appuser2 itself, and a second set of FACL rules that specify the default FACL rules that are applied to files and folders created within folder ./appuser2. The steps you've outlined above set the "default" FACL rules that are applied to files and folders created ...


0

This doesn't answer the exact question asked, but an alternate solution is to have the log live on a different server / VM, make it append-only using chattr +a and then mount it over the network. This is not without drawbacks, but in my opinion is one of the best approaches to solving this problem.


4

chmod u+r doesn't do what you apparently think it does; what it actually does is make the file readable by its owner. Which, I'm going to guess, it already was. chmod o+r (make file readable by "others", i.e., not owner/group) would probably work, but security argues against this. Pick one: ls -l /var/log/apache2/error.log ... on my (Debian) system, its ...


2

Run sudo visudo and add this line: Defaults timestamp_timeout=-1 -1 = never timeout the password Also see man 5 sudoers Though the above solution attracts security concerns. Please follow this link to set up sudo to run without password for specific commands.


4

I can think of many solutions for this specific problem : (A) Configure sudo access such that your username does not require password for tail command (or for all commands, if you so require) Refer sudo and sudoers Documentation for this. (B) Configure sudo access with negative timeout. Default timeout is 5 minutes , after that you will have to reenter the ...


3

It's because you are too early, if you wait until the UIDs are changed then your process runs as basic4_pwned. This worked for me: ./shellcode4js "test" & PID=$! sleep 0.0005 kill -SIGSTOP $PID grep ^Uid /proc/$PID/status Another try is to add a delay with usleep() and send the SIGSTOP later during that sleep. Then the programm runs with basic4_pwned ...


0

This is much easier than suggested by other answers. No need to format, reboot or use live CD. su root # then enter your password to switch to root user chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo exit # to get back to the original user This is the easiest way to fix this issue. Explanation, sudo is corrupted (I know corrupted is the ...


1

Is the program running on a filesystem that honors the setuid bit on files (mount -o nosuid)? If I were debugging this, I would print the output of getuid() and geteuid() on program startup, to see whether the setuid bit is being honored.


0

@hildred noted this in a comment above. I'll expand it into an Answer as I think it's the correct and highly recommended answer. The super command … allows specified users to execute scripts (or other commands) as if they were root; or it can set the uid, gid, and/or supplementary groups on a per-command basis before executing the command. It is ...


1

Following these steps: Try sudo Try chmod +x script_path If security does not matter, run chmod 777 script_path


0

Setuid and setgid flags are ignored for shell scripts, for security reasons.


0

I'm having a similar issue on OpenSUSE 13.2 with KDE. I set full repaint in desktop effects, and when I reboot, that doesn't work even though it is still set. When I change a setting, save it, revert it, save it, then it works fine.


0

Short answer, loggedin with root reside virtual consoles(i.e. Ctrl+Alt+N), then start pulseaudio daemon and play video: /usr/bin/pulseaudio --start mplayer -vo fbdev2 test.mp4 [Important] tried with /usr/bin/pulseaudio --system is not required here. And you MUST reside root(not sudo or even su) AND virtual consoles to perform all the step including ...


0

That's an interesting observation; the only concrete evidence I could find, so far, is this SCAP mailing list thread talking about the change from RHEL5's default permissions of 0400 to RHEL6's default of 0. You can also observe that in the list of Common Configuration Enumartions on the Working Group's now-archived website.


0

The directory abc is a mountpoint of a filesystem belonging to a different server, hence the permissions of the filesystem being shared overrides the permissions set on the mountpoint. The user(me) does not have the execute permission on the original filesystem and hence not able to get into the directory.


0

The shadow file is specifically designed to be read ONLY by root. The point in this file is to prevent people from seeing your encrypted passwords because there are commands like "crack" than can figure out many passwords from their encrypted values. Prior to introduction of the shadow file the encrypted passwords were stored in /etc/passwd and ...


2

I realized that I forgot to mention that I aborted cp -a after checking the destination in another terminal as I was copying 300+ gb of data. Thanks to Gilles' comment I started testing to see whether it only happens to directories or not. As the tests prove below, basically all files are written as root and the old attributes are applied to the ...


1

That looks very odd to me - what you described is definitely not a known issue. I've used cp -a extensively (including to clone entire Linux systems) and the only time I've seen a problem, it was caused by a bug in XFS (which was later fixed). My guess is that it's a bug in btrfs, which is still undergoing extensive development. Is it reproducible? Can you ...


2

Low-level control of USB devices is done via /dev/bus/usb, and you need to set the right permissions on the device there. The way to do that is with a udev rule: Create a file (such as /etc/udev/rules.d/52_local-usbtiny.rules) with: SUBSYSTEM=="usb", ATTR{idVendor}=="1781", ATTR{idProduct}=="0c9f", MODE="664", GROUP="plugdev" That sets the group to ...


2

This comment was right; the web server was started before I added www-data to the git group. The web server was restarted when I rebooted for other reasons and the problem went away.


2

If you want to skip the unreadable files: find /external/hd/folder ! -readable -print >unreadable_files rsync -a --exclude-from=unreadable_files /external/hd/folder/ /local/folder This assumes that you're using GNU find, and that your filenames don't have embedded newlines. If you want to copy all files, regardless of whether they are readable or not ...


1

If you mount the external HDD to your system locally, then it's not remote. Unless I misunderstood and your HDD is running a rsync daemon and say, connecting over a network? But forget that, can you just mount the drive locally and as @mjturner says, all you need to do is make sure you run rsync as root and it's a direct copy sudo rsync -a ...


0

Why not just use rsync to copy all of the files on the external HDD to the system HDD? It will not re-copy files that already exist. Of course, be sure to do the copy as root to ensure that you copy all files and preserve permissions.


1

You'll probably want to write a rule for udev. Assuming no changes to udev.conf, your rules file should be placed into /etc/udev/rules.d/; it may help you to crib from packages' rules which may be found in /lib/udev/rules.d/. Writing good rules is a bit of an acquired art, but you could start with something simple if you have no other ttyACM* devices: # ...


0

Default permissions are based on your umask setting. RHEL 6.6: # umask 0022 I don't believe that has changed by default - can't find anything authoritative. umask is something that you should set as part of the default profile.


0

Normally the webserver user owns that directory. If you're using apache2 then usually its www-data user/group that owns them. To check which user is running apache2 u can use: sudo ps aux | grep apache[2] Or if you dont use sudo, u can use: su ps aux | grep apache[2] You may have 1 process that root runs, but the rest should be the apache2 user. To ...


2

When you access the directory via a server/browser combination of any kind, your credentials are not shared, so the server does not know that the person accessing the files is you. Try chmod a+x directory_B and chmod a+r directory_B/*


0

A live cd rom is not writable when running a operating system from it. I really don't think you could implement any sort of persistence to it. A USB drive however can be used to install a operating system on, that would then allow you to obtain the persistence you require


0

Just install the Live CD on a USB stick, as you would do on a normal hard drive. This worked for me a few years ago. I booted my Live ISO in a VirtualBox, mounted the USB and installed it like any Ubuntu (Debian) derived distro. I hope my answer is not to short :)


0

You can try lstat, or lstat64 if it is a 64-bit machine.


4

GNU stat is available in the SUNWgnu-coreutils package. If you're not able to install that, the pkgproto command is an alternative. From the manual page: pkgproto /bin=bin /usr/bin=usrbin /etc=etc f none bin/sed=/bin/sed 0775 bin bin f none bin/sh=/bin/sh 0755 bin daemon f none bin/sort=/bin/sort 0755 bin bin f none usrbin/sdb=/usr/bin/sdb 0775 ...


2

try as root find wherever -type d -name ... -exec chown Me {} \; where -type d apply to dir only -name ... your regexp -exec chown Me {} \; use chown on find dir. you must be root to chown.


4

I may have misunderstood. But you can recursively use chmod and chown eg. chown -R username:username /path/directory To recursively apply permission 700 you can use: chmod -r 700 /path/directory Of course the above is for Linux so not sure if mac osx is the same. EDIT: Yea sorry forgot to mention you need to be root to chown something, I just assumed ...


0

you must to use the new version of authbind supporting IPV6: http://ftp.debian.org/debian/pool/main/a/authbind/ or http://www.filewatcher.com/m/authbind_2.1.1.tar.gz.14407-0.html ftp://ftp.debian.com/debian/pool/main/a/authbind/authbind_2.1.1.tar.gz tar zxvf /home/.../authbind_2.1.1.tar.gz -C /your/path/ cd /your/path/authbind-2.1.1 make make install ...


3

Sudo and the /etc/sudoers file aren't just for granting users full root access. You can edit the sudoers file with an existing sudo user, with the command sudo visudo You can group the commands that you want to grant access to like below: Cmnd_Alias SHUTDOWN_CMDS = /sbin/poweroff, /sbin/halt, /sbin/reboot Cmnd_Alias UPDATE_COMMANDS = /usr/bin/apt-get ...


0

Check if the attributes for the folder are proper. Do this: lsattr It should give some output like this: ----i--------e-- ./databases Now, if the i attribute is present, it means that the folder is not editable. So, you should remove that attribute and keep only the e attribute. To do this, do: sudo chattr =e databases/ After this, you can now ...



Top 50 recent answers are included