Re: permissions on /dev/tty

Joe Pfeiffer writes: > I have a laptop with a recent Debian install, which seems to have > incorrect permissions on /dev/tty > > crw--w 1 root tty 5, 0 Feb 16 08:51 /dev/tty Ah, found it. I somehow had a /etc/systemd/system/getty.target.wants/getty@tty.service file. Found it looking through

Re: Permissions on NFS mounts

On Thu, Dec 10, 2020 at 04:48:36PM +0300, Reco wrote: I just like to remind you the original question: Is there a way to put an account "beyond use", in any way including su, sudo etc, *In any way* includes the way I've described above IMO. So you're asking if there's a way to prevent someone

Re: Permissions on NFS mounts

On Thu, Dec 10, 2020 at 10:42:36AM -0500, Greg Wooledge wrote: In the context of the original question, having a consistent set of local user accounts (name/UID pairs) across all of your systems in an NFS environment is useful for making sure all files have consistent ownership. Even on the syst

Re: Permissions on NFS mounts

On Wed, Dec 09, 2020 at 03:38:21PM -0500, Paul M Foster wrote: I have two users on the client: paulf 1000 and nancyf 1001. On the server, I have two users: pi 1000 and paulf 1001. I can mount the NFS share from the server to /mnt on my client. But any files belonging to me (user 1001 on the serve

Re: Permissions on NFS mounts

On Thu, Dec 10, 2020 at 03:35:50PM +, Tixy wrote: > Why would you execute sudo or su on the target machine to change to one > of these unneeded users, presumably you can do whatever mischief is > your aim by using the account you are executing su or sudo from. Or by > changing to another valid

Re: Permissions on NFS mounts

On Thu 10 Dec 2020 at 16:48:36 (+0300), Reco wrote: > On Thu, Dec 10, 2020 at 03:36:47PM +0200, Andrei POPESCU wrote: > > At least on Debian sudo has to be explicitly configured to allow a > > regular user to use '-u' with another user name. We can only assume the > > admin had good reasons to th

Re: Permissions on NFS mounts

On Thu, 2020-12-10 at 16:48 +0300, Reco wrote: > On Thu, Dec 10, 2020 at 03:36:47PM +0200, Andrei POPESCU wrote: > > On Jo, 10 dec 20, 13:34:55, Reco wrote: > > > On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > > > > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > > > > On Thu, Dec 10

Re: Permissions on NFS mounts

On Thu, Dec 10, 2020 at 03:36:47PM +0200, Andrei POPESCU wrote: > On Jo, 10 dec 20, 13:34:55, Reco wrote: > > On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > > > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > >

Re: Permissions on NFS mounts

On Jo, 10 dec 20, 13:34:55, Reco wrote: > On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > > > > > passwd -l/--lock > > > > > > sudo -u /bin/bash -i > > > >

Re: Permissions on NFS mounts

On 10/12/2020 09:10, Mark Fletcher wrote: > On Wed, Dec 09, 2020 at 03:54:10PM -0500, Dan Ritter wrote: >> Paul M Foster wrote: >>> I have two users on the client: paulf 1000 and nancyf 1001. On the >>> server, I have two users: pi 1000 and paulf 1001. I can mount the NFS >>> share from the serve

Re: Permissions on NFS mounts

On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > > > passwd -l/--lock > > > > sudo -u /bin/bash -i > > > > That little trick defeats "locked" account status, an

Re: Permissions on NFS mounts

On Jo, 10 dec 20, 12:52:56, Reco wrote: > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > passwd -l/--lock > > sudo -u /bin/bash -i > > That little trick defeats "locked" account status, an absence of a > password and even /usr/sbin/nologin set as a default shell. With

Re: Permissions on NFS mounts

Hi. On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > Left alone, having unneeded users on a given machine could be a > > security threat, at least in the sense that it provides a greater than > > necessary attackable surface area. What can be done about that? > > Obvi

Re: Permissions on NFS mounts

Hi. On Thu, Dec 10, 2020 at 09:10:42AM +, Mark Fletcher wrote: > This brings up an interesting thought. In the situation where you align > user IDs across a number of machines for ths purpose, you'll inevitably > end up with situations where users are created on some of the machines

Re: Permissions on NFS mounts

On Jo, 10 dec 20, 09:10:42, Mark Fletcher wrote: > > This brings up an interesting thought. In the situation where you align > user IDs across a number of machines for ths purpose, you'll inevitably > end up with situations where users are created on some of the machines > only for the purpose

Re: Permissions on NFS mounts

On Wed, Dec 09, 2020 at 03:54:10PM -0500, Dan Ritter wrote: > Paul M Foster wrote: > > I have two users on the client: paulf 1000 and nancyf 1001. On the > > server, I have two users: pi 1000 and paulf 1001. I can mount the NFS > > share from the server to /mnt on my client. But any files belongin

Re: Permissions on NFS mounts

Paul M Foster wrote: > I have two users on the client: paulf 1000 and nancyf 1001. On the > server, I have two users: pi 1000 and paulf 1001. I can mount the NFS > share from the server to /mnt on my client. But any files belonging to > me (user 1001 on the server) look like they belong to nancy (

One way to send emails to LAN hosts and to ISP, was Re: Permissions and delivery of LAN email by exim

On Sat 17 Aug 2019 at 07:20:45 (-), Curt wrote: > On 2019-08-16, Greg Wooledge wrote: > > On Fri, Aug 16, 2019 at 02:20:09PM -0500, David Wright wrote: > >> AIUI exim should be able to deliver emails into a user's mbox, but > >> I'm confused about how exim is meant to do that, because it runs

Re: Permissions and delivery of LAN email by exim

On 2019-08-16, Greg Wooledge wrote: > On Fri, Aug 16, 2019 at 02:20:09PM -0500, David Wright wrote: >> AIUI exim should be able to deliver emails into a user's mbox, but >> I'm confused about how exim is meant to do that, because it runs as >> user Debian-exim, but mailbox permissions are normally

Re: Permissions and delivery of LAN email by exim

On Fri, Aug 16, 2019 at 02:20:09PM -0500, David Wright wrote: > AIUI exim should be able to deliver emails into a user's mbox, but > I'm confused about how exim is meant to do that, because it runs as > user Debian-exim, but mailbox permissions are normally group:mail. I don't know much about exim

Re: Permissions error with Postfix + Cyrus

On 15/2/19 13:59, Reco wrote: > Hi. Hi, Reco. Thanks for your reply. > Its' expected. /var/run is a symlink to /run, in-memory filesystem > (tmpfs). Which becomes empty after each reboot. > Every time you boot, systemd calls systemd-tmpfiles with the > following config: > > $ cat /usr/lib

Re: Permissions error with Postfix + Cyrus

Hi. On Fri, Feb 15, 2019 at 01:18:50PM -0300, Daniel Bareiro wrote: > But I have noticed that after doing a reboot I have this problem again. Its' expected. /var/run is a symlink to /run, in-memory filesystem (tmpfs). Which becomes empty after each reboot. Every time you boot, systemd cal

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Fri 28 Oct 2016 at 18:34:10 (-0500), Richard Owlett wrote: > On 10/28/2016 5:17 PM, Brian wrote: > >On Fri 28 Oct 2016 at 15:42:27 -0500, Richard Owlett wrote: > > > >>Be aware sir that you are the cause of: > >>multiple renditions of the "Alleluia Chorus" [courtesy Handle] at > > >>10^^Bels

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sun 30 Oct 2016 at 09:19:04 -0400, rhkra...@gmail.com wrote: > On Sunday, October 30, 2016 08:54:45 AM Brian wrote: > > There are some good things which have come out of this discussion. To > > use cfdisk, fdisk, dd, mkfs.vfat and grub-install a user has to be > > root. Being able to mount as n

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sunday, October 30, 2016 08:54:45 AM Brian wrote: > There are some good things which have come out of this discussion. To > use cfdisk, fdisk, dd, mkfs.vfat and grub-install a user has to be > root. Being able to mount as non-root is neither here nor there on > jessie and stretch for the purpose

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sun 30 Oct 2016 at 12:22:43 +0300, Reco wrote: > On Sat, 29 Oct 2016 23:49:17 +0100 > Brian wrote: > > > They do indeed. Six years. Do you get the feeling it is getting on for > > unmaintained. (And a wiki page with HAL on it! I ask you). But software > > changes. Then wiki pages change. >

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sunday 30 October 2016 00:19:34 rhkra...@gmail.com wrote: > On Saturday, October 29, 2016 07:00:02 PM Brian wrote: > > What happened to curiosity? > > Curiosity is a function of available resources, among them time. The OP says that he has ample time because he is retired and this is his retir

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

Hi. On Sat, 29 Oct 2016 23:49:17 +0100 Brian wrote: > On Sat 29 Oct 2016 at 23:23:52 +0300, Reco wrote: > > > On Sat, 29 Oct 2016 19:15:53 +0100 > > Brian wrote: > > > > > I wish you had addressed the "equal exposure" question. Desktops are not > > > the only environments in town. Lea

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Saturday, October 29, 2016 07:00:02 PM Brian wrote: > What happened to curiosity? Curiosity is a function of available resources, among them time.

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sat 29 Oct 2016 at 16:28:24 -0400, rhkra...@gmail.com wrote: > On Saturday, October 29, 2016 03:53:21 PM Brian wrote: > > On Sat 29 Oct 2016 at 15:28:14 -0400, rhkra...@gmail.com wrote: > > > On Saturday, October 29, 2016 08:54:59 AM Reco wrote: > > > > On Sat, 29 Oct 2016 08:16:18 -0400 > > >

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sat 29 Oct 2016 at 23:23:52 +0300, Reco wrote: > On Sat, 29 Oct 2016 19:15:53 +0100 > Brian wrote: > > > I wish you had addressed the "equal exposure" question. Desktops are not > > the only environments in town. Leaving non-policykit users out in the > > cold is not an option. > > True, tha

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Saturday, October 29, 2016 03:53:21 PM Brian wrote: > On Sat 29 Oct 2016 at 15:28:14 -0400, rhkra...@gmail.com wrote: > > On Saturday, October 29, 2016 08:54:59 AM Reco wrote: > > > On Sat, 29 Oct 2016 08:16:18 -0400 > > > > > > rhkra...@gmail.com wrote: > > > > I'm not the OP or anybody that h

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

Hi. On Sat, 29 Oct 2016 19:15:53 +0100 Brian wrote: > On Sat 29 Oct 2016 at 18:48:11 +0300, Reco wrote: > > > On Sat, 29 Oct 2016 15:09:09 +0100 > > Brian wrote: > > > > > On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote: > > > > > > > On Sat, 29 Oct 2016 08:16:18 -0400 > > > > rhkra

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sat 29 Oct 2016 at 15:28:14 -0400, rhkra...@gmail.com wrote: > On Saturday, October 29, 2016 08:54:59 AM Reco wrote: > > On Sat, 29 Oct 2016 08:16:18 -0400 > > rhkra...@gmail.com wrote: > > > > I'm not the OP or anybody that has participated in this thread so far. > > > > [1] tells me otherwi

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Saturday, October 29, 2016 08:54:59 AM Reco wrote: > On Sat, 29 Oct 2016 08:16:18 -0400 > rhkra...@gmail.com wrote: > > I'm not the OP or anybody that has participated in this thread so far. > > [1] tells me otherwise, for the 'participation' part. I take it that > this e-mail I'm replying to

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sat 29 Oct 2016 at 18:48:11 +0300, Reco wrote: > On Sat, 29 Oct 2016 15:09:09 +0100 > Brian wrote: > > > On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote: > > > > > On Sat, 29 Oct 2016 08:16:18 -0400 > > > rhkra...@gmail.com wrote: > > > > > > > I'll say that the wiki page gave no hint as t

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

Hi. On Sat, 29 Oct 2016 15:09:09 +0100 Brian wrote: > On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote: > > > On Sat, 29 Oct 2016 08:16:18 -0400 > > rhkra...@gmail.com wrote: > > > > > I'll say that the wiki page gave no hint as to which of the three options > > > to > > > install, o

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote: > On Sat, 29 Oct 2016 08:16:18 -0400 > rhkra...@gmail.com wrote: > > > I'll say that the wiki page gave no hint as to which of the three options > > to > > install, or any hint that one might work better than another. > > The page is describing

Re: Permissions for an entire PARTITION

Richard Owlett: > > My original question had (apparently incorrectly assume that partitions > handled user/group/world permissions in the same manner as file systems. Even if you found a solution to your problem, this sentence does not make much sense and I still assume you are confused about a f

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

Hi. On Sat, 29 Oct 2016 08:16:18 -0400 rhkra...@gmail.com wrote: > On Saturday, October 29, 2016 05:17:30 AM Reco wrote: > > On Fri, 28 Oct 2016 18:34:10 -0500 > > Richard Owlett wrote: > > > > But it gave no useful info! > > > > I dunno ;). Quoting the page, this:

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Saturday, October 29, 2016 05:17:30 AM Reco wrote: > On Fri, 28 Oct 2016 18:34:10 -0500 > Richard Owlett wrote: > > But it gave no useful info! > > I dunno ;). Quoting the page, this: > > Installing GRUB on the USB Stick > Install pmount, udevil or udisks2 and use one of

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

Hi. On Fri, 28 Oct 2016 18:34:10 -0500 Richard Owlett wrote: > On 10/28/2016 5:17 PM, Brian wrote: > > On Fri 28 Oct 2016 at 15:42:27 -0500, Richard Owlett wrote: > > > >> Be aware sir that you are the cause of: > >> multiple renditions of the "Alleluia Chorus" [courtesy Handle] at >

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On 10/28/2016 5:17 PM, Brian wrote: On Fri 28 Oct 2016 at 15:42:27 -0500, Richard Owlett wrote: Be aware sir that you are the cause of: multiple renditions of the "Alleluia Chorus" [courtesy Handle] at > 10^^Bels an "innocent"[snicker] senior citizen is about to have many sleepless nigh

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

On Fri 28 Oct 2016 at 15:42:27 -0500, Richard Owlett wrote: > Be aware sir that you are the cause of: >multiple renditions of the "Alleluia Chorus" [courtesy Handle] at > > 10^^Bels >an "innocent"[snicker] senior citizen is about to have many sleepless > nights >multiple nay-sayers wil

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

Better than what Archimedes did (yes, I know I'm top posting). --| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --| On Fri, 28 Oct 2016, Richard Owlett wrote: > Be aware sir that y

EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

Be aware sir that you are the cause of: multiple renditions of the "Alleluia Chorus" [courtesy Handle] at > 10^^Bels an "innocent"[snicker] senior citizen is about to have many sleepless nights multiple nay-sayers will suffer "EGG ON FACE" *ROFL* ! On 10/28/2016 2:30 PM, Jörg-Vol

Re: Permissions for an entire PARTITION

Did you take a look at the package pmount? I use it to mount external disks. It requires no changes to /etc/fstab. Regards, jvp.

Re: Permissions for an entire PARTITION

On Fri, Oct 28, 2016 at 10:28:54AM -0500, Richard Owlett wrote: > I'll attempt to refine my problem definition. > My primary use case is a laptop: > 1. purchased explicitly for use as a test bed. > 2. whose HD has been erased multiple times in ONE day. > 3. is isolated from ANY network. > 4

Re: Permissions for an entire PARTITION

On 10/25/2016 11:42 AM, Greg Wooledge wrote: On Tue, Oct 25, 2016 at 11:33:23AM -0500, Richard Owlett wrote: On 10/25/2016 10:40 AM, Greg Wooledge wrote: The simplest way would be to synchronize your UID across all your installed operating systems. If your UID is, let's say, 1000 on every syst

Re: Permissions for an entire PARTITION

On Wed, 2016-10-26 at 08:28 -0400, Greg Wooledge wrote: > cd /each/file/system/one/at/a/time > find . -xdev -user 500 -exec chown 1000 {} + > cd /the/next/file/system > find . -xdev -user 500 -exec chown 1000 {} + > etc. > > (I would not recommend trying it as one gigantic find from / because > of

Re: Permissions for an entire PARTITION

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Oct 26, 2016 at 08:28:34AM -0400, Greg Wooledge wrote: > Synchronizing your user account's UID across all of your own local > operating system installations is probably easier than most of the > workarounds that have been suggested. We are in

Re: Permissions for an entire PARTITION

Synchronizing your user account's UID across all of your own local operating system installations is probably easier than most of the workarounds that have been suggested. There may not even be any work required -- if you've always just followed the defaults, then your primary user account is prob

Re: Permissions for an entire PARTITION

On Wednesday, October 26, 2016 04:09:41 AM to...@tuxteam.de wrote: > On Tue, Oct 25, 2016 at 11:33:23AM -0500, Richard Owlett wrote: > > On 10/25/2016 10:40 AM, Greg Wooledge wrote: > > >On Tue, Oct 25, 2016 at 10:32:29AM -0500, Richard Owlett wrote: > > >>I'm in a multi-boot environment, multiple

Re: Permissions for an entire PARTITION

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Oct 25, 2016 at 11:33:23AM -0500, Richard Owlett wrote: > On 10/25/2016 10:40 AM, Greg Wooledge wrote: > >On Tue, Oct 25, 2016 at 10:32:29AM -0500, Richard Owlett wrote: > >>I'm in a multi-boot environment, multiple installs of Debian. > >>I wa

Re: Permissions for an entire PARTITION

Richard Owlett: > On 10/25/2016 10:40 AM, Greg Wooledge wrote: >> >> The simplest way would be to synchronize your UID across all your >> installed operating systems. If your UID is, let's say, 1000 on every >> system, and the files on the partition are owned by user 1000, then >> user 1000 (you)

Re: Permissions for an entire PARTITION

On Tue, Oct 25, 2016 at 11:33:23AM -0500, Richard Owlett wrote: > On 10/25/2016 10:40 AM, Greg Wooledge wrote: > >The simplest way would be to synchronize your UID across all your > >installed operating systems. If your UID is, let's say, 1000 on every > >system, and the files on the partition are

Re: Permissions for an entire PARTITION

On 10/25/2016 10:40 AM, Greg Wooledge wrote: On Tue, Oct 25, 2016 at 10:32:29AM -0500, Richard Owlett wrote: I'm in a multi-boot environment, multiple installs of Debian. I want all install to have read/write/execute permissions. The partition will effectively be serving as a common scratch pad

Re: Permissions for an entire PARTITION

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Oct 25, 2016 at 11:40:10AM -0400, Greg Wooledge wrote: > On Tue, Oct 25, 2016 at 10:32:29AM -0500, Richard Owlett wrote: > > I'm in a multi-boot environment, multiple installs of Debian. > > I want all install to have read/write/execute permiss

Re: Permissions for an entire PARTITION

On Tue, Oct 25, 2016 at 10:32:29AM -0500, Richard Owlett wrote: > I'm in a multi-boot environment, multiple installs of Debian. > I want all install to have read/write/execute permissions. > The partition will effectively be serving as a common scratch pad > in order to exchange information. There

Re: permissions: can you force ACL to be effective over unix perms?

On Sat, Jan 18, 2014 at 7:07 AM, Joel Rees wrote: > I have a little more time to work through what you originally wrote, > sans certain assumptions I had when I originally responded. > > (And I didn't intend to post this off-list, so I'm posting it again, on list. > > Note -- if you aren't sure ho

Re: permissions: can you force ACL to be effective over unix perms?

I have a little more time to work through what you originally wrote, sans certain assumptions I had when I originally responded. (And I didn't intend to post this off-list, so I'm posting it again, on list. Note -- if you aren't sure how to code some simple test routines using the C functions, le

Re: permissions on /dev/nvidia*

On Mi, 15 ian 14, 13:13:34, Uli Wannek wrote: > It is a very old thread, sorry, but i stumbled upon and meanwhile found > a solution: > > nvidia supplies > /etc/modprobe.d/nvidia-kernel-common.conf > originally containing: > alias char-major-195* nvidia > options nvidia NVreg_DeviceFileUID=0

Re: permissions on /dev/nvidia*

It is a very old thread, sorry, but i stumbled upon and meanwhile found a solution: nvidia supplies /etc/modprobe.d/nvidia-kernel-common.conf originally containing: alias char-major-195* nvidia options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 \ NVreg_DeviceFileMod

Re: permissions: can you force ACL to be effective over unix perms?

Le 15/01/2014 00:21, Bob Goldberg a écrit : On Tue, Jan 14, 2014 at 7:13 AM, Joel Rees > wrote: Caveat. I don't have the patience to work with ACLs, mostly because I can't see how they could really work without bringing a system to its knees. To be hones

Re: permissions: can you force ACL to be effective over unix perms?

On Tue, Jan 14, 2014 at 05:21:18PM -0600, Bob Goldberg wrote: > I have 2 classes of users - SFTP users (customers), and SFTP managers > (company users that manage customer data). > > I want a highly secure and privacy safe SFTP server. But I also want it to > appear to users as simple and easy as

Re: permissions: can you force ACL to be effective over unix perms?

On 15/01/14 10:00, Bob Goldberg wrote: > On Mon, Jan 13, 2014 at 5:40 PM, Scott Ferguson > > wrote: > > I've followed the posts in this thread, dealing with the various > tangents it's taken won't help you, probably the reason why it's > re

Re: permissions: can you force ACL to be effective over unix perms?

On Tue, Jan 14, 2014 at 7:13 AM, Joel Rees wrote: > Caveat. I don't have the patience to work with ACLs, mostly because I > can't see how they could really work without bringing a system to its > knees. > > To be honest - ACL's were by far my first choice for solving my problem. There is no doubt

Re: permissions: can you force ACL to be effective over unix perms?

On Mon, Jan 13, 2014 at 5:40 PM, Scott Ferguson < scott.ferguson.debian.u...@gmail.com> wrote: > I've followed the posts in this thread, dealing with the various > tangents it's taken won't help you, probably the reason why it's > received little attention. > > good point; noted, and TY. > On 11

Re: permissions: can you force ACL to be effective over unix perms?

On 15/01/14 00:13, Joel Rees wrote: > Caveat. I don't have the patience to work with ACLs, mostly because I > can't see how they could really work without bringing a system to its > knees. > > On Tue, Jan 14, 2014 at 8:04 AM, Bob Goldberg wrote: >> [...] >>> I may be wrong here, but how could ACL

Re: permissions: can you force ACL to be effective over unix perms?

Caveat. I don't have the patience to work with ACLs, mostly because I can't see how they could really work without bringing a system to its knees. On Tue, Jan 14, 2014 at 8:04 AM, Bob Goldberg wrote: > [...] >> I may be wrong here, but how could ACLs override the native >> permissions system rand

Re: permissions: can you force ACL to be effective over unix perms?

On Sat, Jan 11, 2014 at 09:41:19AM +0900, Joel Rees wrote: > But I may be wrong.I don't use ACLs. This normally sets alarm bells off in my head... > I may be wrong here, but how could ACLs override the native > permissions system randomly without opening tons of new opportunities > for discoveri

Re: permissions: can you force ACL to be effective over unix perms?

I've followed the posts in this thread, dealing with the various tangents it's taken won't help you, probably the reason why it's received little attention. On 11/01/14 10:50, Bob Goldberg wrote: > running wheezy. > > I have a dir w/ unix perm = 750 > IE: > root@wheezy:/home/chtest/home# ls -l >

Re: permissions: can you force ACL to be effective over unix perms?

Joel; i'm confused by your comments, which i'll address individually; with apologies in advance to the group for length, and content: On Fri, Jan 10, 2014 at 6:41 PM, Joel Rees wrote: > On Sat, Jan 11, 2014 at 8:50 AM, Bob Goldberg wrote: > > > > So - Is there a way to force ACL perms to dicta

Re: permissions: can you force ACL to be effective over unix perms?

On Sat, Jan 11, 2014 at 8:50 AM, Bob Goldberg wrote: > running wheezy. > > I have a dir w/ unix perm = 750 > IE: > root@wheezy:/home/chtest/home# ls -l > drwxr-s--- 3 rootchadm 4096 Jan 9 14:12 ftptest > > I added an acl g perm using: # setfacl -m g:chadm:rwx ftptest > this, unfortunately, c

Re: Permissions

On 08/27/2013 03:31 PM, Steven Post wrote: On Tue, 2013-08-27 at 13:43 -0400, Ethan Rosenberg wrote: Dear List - I apologize for this "needle in a haystack" but... This was originally posted on the PHP list, but has changed into a Debian question... Tried to run the program, that we have be

Re: Permissions

On Tue, 2013-08-27 at 13:43 -0400, Ethan Rosenberg wrote: > Dear List - > > I apologize for this "needle in a haystack" but... > > This was originally posted on the PHP list, but has changed into a > Debian question... > > Tried to run the program, that we have been discussing,{on the PHP list

Re: Permissions

Hi Ethan, you wrote about a 403 error, so I assume you invoke the script by calling a webserver via browser. In that case the webserver needs the permission to access /var/www and to read StoreInventory.php. By default the webserver runs as user/group www-data (it can be changed in the webservers

Re: permissions/sudo/sudoers

Bob Proulx wrote: > In the case of the recent sudo there is the /etc/sudoers.d/* files and > I always create a new uniquely named local file there for my > configuration and I no longer edit the /etc/sudoers file. This is > also a pain because it means I can't use the default 'visudo' to edit > t

Re: permissions/sudo/sudoers

On Tue, 2 Apr 2013 12:43:56 -0600 Bob Proulx wrote: > (Use 'visudo -f /etc/sudoers.d/local-foo' explicitly.) But > it makes upgrades easier so I do it this way. What is so difficult about that and sudoers could be for users and sudoers.d for dev changes. You could even only warn upon uncommente

Re: permissions/sudo/sudoers

Kevin Chadwick wrote: > Personally I think it would be great if package devs added perhaps > commented by default lines sudoers or to a file in sudoers.d This compelled me to reply. The problem with commented template files is that if you change the file then upon every package upgrade the file

Re: permissions/sudo/sudoers

On Tue, 2 Apr 2013 01:45:53 +0200 sp113438 wrote: Personally I think it would be great if package devs added perhaps commented by default lines sudoers or to a file in sudoers.d There is no need for groups and logging back in for the average system and sudoers changes take immediate effect wher

Re: permissions/sudo/sudoers

On 01/04/13 07:18 PM, John Lindsay wrote: If I try 'sudo' in a terminal window, it asks for my password. If I try 'root's' password I get 'user not in sudoers file'. If I try my user password I get 'user not in sudoers file. this incident will be reported.' I'm trying to run 'sudo apt-get ins

Re: permissions/sudo/sudoers

On Mon, Apr 1, 2013 at 7:18 PM, John Lindsay wrote: > > If I try 'sudo' in a terminal window, it asks for my password. If I try > 'root's' password I get 'user not in sudoers file'. If I try my user > password I get 'user not in sudoers file. this incident will be reported.' > > I'm trying to run

Re: permissions/sudo/sudoers

On Mon, 01 Apr 2013 19:18:48 -0400 John Lindsay wrote: > If I try 'sudo' in a terminal window, it asks for my password. If I > try 'root's' password I get 'user not in sudoers file'. If I try my > user password I get 'user not in sudoers file. this incident will be > reported.' > > I'm trying to

Re: permissions/sudo/sudoers

John Lindsay wrote: > If I try 'sudo' in a terminal window, it asks for my password. If I > try 'root's' password I get 'user not in sudoers file'. It asks for your password. If you give it root's password then it should fail since root's password is different from your password. > If I try my u

Re: Itroductry info on permission issues and implications - where? -was [Re: permissions on a Verbatim USB external drive]

- Original Message - From: Joao Luis Meloni Assirati To: debian-user@lists.debian.org Sent: 3/13/2013 7:31:19 PM Subject: Re: Itroductry info on permission issues and implications - where? -was [Re: permissions on a Verbatim USB external drive] > João Luis Meloni Assirati wr

Re: Itroductry info on permission issues and implications - where? -was [Re: permissions on a Verbatim USB external drive]

> João Luis Meloni Assirati wrote: >> [snip] >> >> Since vfat filesystems don't hold UNIX permissions, it has >> to be mounted with the umask and/or uid, gid options. If it >> is plugged through USB and you have a mount desktop service >> communicating with dbus, all should be automatic. However, >

Itroductry info on permission issues and implications - where? -was [Re: permissions on a Verbatim USB external drive]

João Luis Meloni Assirati wrote: [snip] Since vfat filesystems don't hold UNIX permissions, it has to be mounted with the umask and/or uid, gid options. If it is plugged through USB and you have a mount desktop service communicating with dbus, all should be automatic. However, if User mounts it

Re: permissions on a Verbatim USB external drive

On Wednesday 13 March 2013 14:55:01 João Luis Meloni Assirati wrote: > Em 13-03-2013 07:37, Lisi Reisz escreveu: > > On Tuesday 12 March 2013 18:58:16 John L. Cunningham wrote: > >> On Tue, Mar 12, 2013 at 05:31:57PM +, Lisi Reisz wrote: > >>> The Verbatim belongs to User, and needs to function

Re: permissions on a Verbatim USB external drive

Em 13-03-2013 07:37, Lisi Reisz escreveu: On Tuesday 12 March 2013 18:58:16 John L. Cunningham wrote: On Tue, Mar 12, 2013 at 05:31:57PM +, Lisi Reisz wrote: The Verbatim belongs to User, and needs to function on his box. But it cannot be written to from his box, even as root, and returns

Re: permissions on a Verbatim USB external drive

On Tuesday 12 March 2013 18:58:16 John L. Cunningham wrote: > On Tue, Mar 12, 2013 at 05:31:57PM +, Lisi Reisz wrote: > > The Verbatim belongs to User, and needs to function on his box. But it > > cannot be written to from his box, even as root, and returns "access > > denied" to most files an

Re: permissions on a Verbatim USB external drive

On Tue, Mar 12, 2013 at 05:31:57PM +, Lisi Reisz wrote: > > The Verbatim belongs to User, and needs to function on his box. But it > cannot be written to from his box, even as root, and returns "access denied" > to most files and directories that I try to copy over. What is the filesystem

Re: Permissions Problem

On 10/15/2012 09:52 AM, Ralf Mardorf wrote: On Mon, 2012-10-15 at 08:46 -0400, Mark Neidorff wrote: user numbers I suspect the term should be "user IDs". If I list my Debian from Arch Linux, it does look like that: [spinymouse@archlinux ~]$ id uid=1000(spinymouse) gid=100(users) groups=100(us

Re: Permissions Problem

Mark Neidorff wrote: On Sunday 14 October 2012 11:06:31 am Stephen P. Molnar wrote: I have a HD on my system, sdc1 which has root root ownership. I created a directory, Apps, to which I gave computation computation ownership (user). I can create a file in the Apps directory without any problems

Re: Permissions Problem

Mark Neidorff wrote: > You are trying to install a RedHat Enterprise Linux package on > Debian. This can be a problem if the user numbers that Debian and > Redhat either conflict or if RedHat makes different assumptions about > user numbers than Debian does. Can you get a Debian package for ecce?

Re: Permissions Problem

On Mon, 2012-10-15 at 15:56 +0200, Ralf Mardorf wrote: > On Mon, 2012-10-15 at 14:03 +0100, Lisi wrote: > > > Can you get a Debian package for ecce? > > > > According to the Debian package list, the answer is no. (I searched on all > > versions.) > > Perhaps wiki.debian.org/Alien could help. >

Re: Permissions Problem

On Mon, 2012-10-15 at 14:03 +0100, Lisi wrote: > > Can you get a Debian package for ecce? > > According to the Debian package list, the answer is no. (I searched on all > versions.) Perhaps wiki.debian.org/Alien could help. Regards, Ralf -- To UNSUBSCRIBE, email to debian-user-requ...@li

Re: Permissions Problem

On Monday 15 October 2012 13:46:03 Mark Neidorff wrote: > On Sunday 14 October 2012 11:06:31 am Stephen P. Molnar wrote: > > I have a HD on my system, sdc1 which has root root ownership. I created > > a directory, Apps, to which I gave computation computation ownership > > (user). I can create a f

Re: Permissions Problem

On Sunday 14 October 2012 11:06:31 am Stephen P. Molnar wrote: > I have a HD on my system, sdc1 which has root root ownership. I created > a directory, Apps, to which I gave computation computation ownership > (user). I can create a file in the Apps directory without any problems > as the user. >

Re: Permissions on UNIX domain sockets

B.R. wrote: > Nginx spawns its worker processes with the user 'nginx' who belongs > to the 'www-data' group. But when Nginx tried to bind on the PHP-FPM > socket, it encountered a 'permission denied' error. Is the primary group for the nginx user "www-data" or something else? Sometimes when a pro

  1   2   3   4   >