New answers tagged

0

I'm assuming you refer to the ChrootDirectory option of OpenSSH. Why must these directories be owned by root and have 755 permissions? Why can't the chrooted user be its owner? Given that chroots are usually used to limit what some process can do by limiting the set of available files, this is useful to prevent any accidents where some ...


2

It looks like you're trying to execute /etc/apt/sources.list. Because it is not a valid executable (it's just a regular ASCII text file) and does not have the execute permission, this won't work. You'll need to use a text editor to modify sources.list, e.g. nano /etc/apt/sources.list.


1

You can do this with sudo (editing the sudoers file, as you suspected) but really shouldn't. I'm pretty sure useradd -o -u 0 whatever will happily add you a new root account. Similarly, usermod -o -u 0 whatever will happily make an existing account into a root account. usermod can also change an account's shell (change the sysadmin's shell). Various groups ...


0

The simple answer is to run a script on a given interval that you choose (say every 15 minutes) that re-assigns ownership of all files in the "upload" directory to a predetermined "admin" user and sets permissions to "644". This will allow all users read-only access to all files in the upload directory including those they uploaded themselves. Of course, you ...


0

You can use this parameters: //host/share /net/share cifs user,noauto,nofail,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10,workgroup=workgroup,credentials=/foo/credentials 0 0 Permissions will be shown as: drwxr-xr-x directory -rwxr-xr-x file


2

If the cron.allow file exists, it lists the users that may use cron. If it does not exist, the cron.deny file is checked. If the cron.deny file exists, it lists the users that may not use cron. This file is not consulted if the cron.allow file exists. If all users are denied the use of cron (as in your case, since the cron.allow file exists, and is empty),...


3

The r means that you can read the directory or the file itself. The x on a directory means that it can be traversed. With the way that you have the permission set in your question, users and groups other than patrick can't enter the directory or list its contents. They can run ls directly on the contents of the directory but it will just return permission ...


1

A file could be hard-linked elsewhere (and on Linux, bind-mounted elsewhere), and that will bypass the permissions of the containing original directory: # mkdir dir; echo yup > dir/in # ln dir/in out # touch out-b; mount --bind dir/in out-b # chmod 700 dir # su user user$ cat out out-b yup yup user$ cat dir/in cat: dir/in: Permission denied user$ ls dir/...


2

THE AHA MOMENT what are those .'s at the end of my permissions listing? [root@ip-OMITTED centos]# ls -lah /etc/openvpn/google-authenticator/ drwxr-xr-x. gauth gauth . drwxr-xr-x. root root .. -rw-------. gauth gauth ryan ...Searchin' the web... So apparently there's this thing called SELinux (security enhanced linux) That is what those dots were at ...


0

The problem (for me) was To show only file name without the entire directory path. ... Only filename is needed- VBoxManage internalcommands createrawvmdk -filename rawdiskonusb.vmdk -rawdisk \.\PhysicalDrive# worked nicely.


0

One method, use crontab to install your new file, see the crontab - option. Obviously you'll then encounter problems updating root's crontabs, but sudo can allow you to do that. /var/spool/cron/crontabs will be used for the final destination location instead /etc/cron.d. For best security (not sure if this is important in your situation), try to do as ...


-1

It looks like you are trying to mount ntfs partition and for some reason it is mounting as read-only mode. If this is the case try installing ntfs-3g and do remount again. It will work. sudo apt-get install ntfs-3g


2

As @stolenmoment points out, the new mountpoint permissions reflect the permissions of the mounted filesystem's root directory. What you are really trying to do is allow world access to the filesystem for this mount, not edit filesystem's actual permission metadata. This can be necessary when mounting a FAT or NTFS filesystem where FAT/NTFS permission ...


1

Of course not. The mount point takes on the identity of the root of the mounted file system.


1

It fails because it tries to change ownership of those respective files. It has nothing to do with permissions on the current directory. Run the command as a root or use sudo. You can change ownership after it gets extracted if you so desire using chown -R <username>:<group> <path> again as a root or using sudo.


1

sudo -i addgroup mygroup addgroup user1 mygroup addgroup user2 mygroup chgrp -R mygroup /home/user1/programs/Output/ chmod -R ug+rwX /home/user1/programs/Output/ find /home/user1/programs/Output/ -type d -exec chmod g+s {} + exit This adds a group called mygroup, adds both users to that group, and changes the group-ownership of /home/user1/programs/Output/ ...


0

# ls -l | grep -e "-rw-r--r--" Use -e for grep it will list all the files with the desired permission.


3

Run the read side of rsync as a dedicated non-root user but with the capability CAP_DAC_READ_SEARCH. The user should have a full view of the filesystem (of course) and access to a copy of /usr/bin/rsync which has this capability. I'm not very familiar with capabilities on Linux but I think this is how to set it up: cp /usr/bin/rsync /usr/local/sbin/rsync-...


0

You would need to run the rsync as a user on the remote system that has read-only rights. E.g. rsync -a read_only_user@target_machine:/path/to/files /backup/location It's worth noting that rsync will only delete files when used with the --delete flag. You might have a look at the rsync wrapper rrsync where you can specify a -ro flag. For your use case I'd ...


1

Set gid on directories only sets the group, not the mode. You will need file access control lists. see What are the different ways to set file permissions etc on gnu/linux setfacl -R -m o:-,d:o:- «dir-name» Explanation: setfacl is used to set the facl (file access control list). -R recurs through existing child files. -m to modify the list o:- set other ...


3

Fakeroot doesn't carry out all the file metadata changes, that's the point: it only pretends to the program that runs under it. Fakeroot does not carry out changes that it can't do, such as changing the owner. It also does not carry out changes that would cause failures down the line. For example, the following code succeeds when run as root, because root ...


1

This is a quirk of fakeroot, required to implement its root-masquerading functionality; as documented in a code comment: if a file is unwritable, then root can still write to it (no matter who owns the file). If we are fakeroot, the only way to fake this is to always make the file writable, readable etc for the real user (who started ...


0

I am guessing you are running the scripts that generate the files in an environment where umask is set to 0077. This prevents the generating program to set any permission bits in the 'group' and 'other' permission bits. Note that the umask is part of any process's inherited environment and typically set from a default 'profile' at login. Any process (shell)...


2

Shell scripts require the x permission bit to be set to be able to be executed directly, such as ./myscript.sh If you create this file and don't chmod +x it, you'll get a permission denied error, as you would expect. However, let's say that the file didn't have the executable bit set. You would still be able to execute the following, which ultimately ...


5

A shell script only needs to be executable if it is to be run as ./scriptname If it is executable, and if it has a valid #!-line pointing to the correct interpreter, then that interpreter (e.g. bash) will be used to run the script. If the script is not executable (but still readable), then it may still be run with an explicit interpreter from the command ...


3

Note that your specification explicitly talks about newly created files. You couldn't even use chmod to change that, since a new file would have some set of permissions when created, before you could use chmod on them. Also, while that Ruby script doesn't run the chmod command/utility, it does use the same underlying system call, so it's practically the ...


1

The umask value is subtracted from the full permission set for an object. This isn't true. Or at least it's inaccurate and simplified to a common case. First, the base value is not "the full set of permissions", but instead whatever the process creating the file sets as the file permissions. Granted, for regular files, this is usually 0666: the idea being ...


0

Because by default files are not executable, while directories are. The "execute" flag on a directory lets you open files that are in it, so is necessary in most cases (the "read" flag lets you list the directory contents, but not open the files in it). The "execute" flag in a regular file makes it executable, and this isn't generally wanted.


1

I suspect you meant to ask specifically about chmod o+x, to enable other (i.e. someone who is neither the user nor a member of the specified group) users to execute the file. chmod a+x is a superset of chmod o+x since it turns on the execute permission for all 3 (user, group, and other). The difference then is the context in which the program will run. With ...


0

A rather large difference is the fact that if you run a program directly, it runs with the rights of your user id, but with sudo, you're using somebody else's user id and their rights: Consider your usual system where /bin/ls is executable by anyone, and /root is readable only by the root user itself: $ /bin/ls /root/test /bin/ls: cannot access '/root/test'...


0

If your working directory is /media/whoami/t9gjkg-tji-gjgj-gogjf-gjgu-i94k4-k5k, then directory t9gjkg-tji-gjgj-gogjf-gjgu-i94k4-k5k is not found, because you're already in it. You can then use sudo chmod 777 . to change the permissions. Or simply use the absolute path to execute the command. This way is independent of the working directory: sudo chmod ...


1

The commands that you enter in the doas.conf file (which you should enter with a full path for safety) has to occur exactly like that on the command line. This means that to power off your system, you would type doas /sbin/poweroff You may obviously set up a handy alias for this: alias poweroff='doas /sbin/poweroff' With that alias in effect, you would ...


Top 50 recent answers are included